ENode框架Conference案例分析系列之 - 业务简介

前言

ENode是一个应用开发框架。经过ENode，咱们能够方便的开发基于DDD+CQRS+EventSourcing+EDA架构的应用程序。以前我已经写了不少关于ENode的架构以及设计原理的文章，可是由于没有和具体的例子结合来进行分析，因此可能不少人仍是没法理解ENode的功能和设计。因此，接下来，我想经过一个较为完整的案例来一步步从业务分析到领域模型设计再到代码实现，以案例的方式讲解ENode如何帮助咱们落实DDD的编码实现。

本文是这个系列的第一篇，因此须要先介绍这个案例的一些业务。

前段时间，我用业余时间开发了一个DDD的案例，叫Conference。它是一个支持多租户的会议管理和预约的系统。这个项目不是我我的想出来的，而是微软的一个CQRS实践的一个开源项目，项目主页：http://cqrsjourney.github.io/

Conference业务简介

Conference是这样一个系统，它提供了一个在线建立会议以及预订会议座位的平台。这个系统的用户有两类：1）客户，能够建立和管理会议；2）会议座位预约者，能够预订会议座位。具体的关键业务描述以下：

1. 客户建立一个会议，并录入会议的基本信息，好比名称、时间段、地点，等；会议建立后，系统会为客户自动生成一个AccessCode，客户能够经过AccessCode访问本身建立的会议；
2. 客户定义某个会议的座位类型，能够定义多个，每一个座位类型包含的信息有：名称、座位价格、座位数量；
3. 客户发布或取消发布某个会议，当一个会议发布后，预订者就能够在线预订会议的座位了；若是取消发布，则该会议对预订者不可见；只有未发布状态的会议才能修改；
4. 预订者在预订会议座位时，会生成订单，订单须要进行支付才会生效；
5. 订单生成后，预订者能够有15分钟的时间付款，超过15分钟，订单预约的座位就会回收，容许其余人预约；
6. 订单生成后，系统会为预订者生成一个AccessCode，用户能够经过AccessCode查看本身的订单；
7. 预订者成功预订了座位后，能够指定每一个座位的实际参会人信息；
8. 客户（会议的Owner）能够管理他建立的每一个会议的全部订单，好比能够查看该会议的全部订单以及参会人信息，以方便联系参会人；

结束语

经过上面的业务介绍，咱们不难理解，这个系统本质是一个简易的电子商务系统。它提供了商品管理、下订单、支付三大功能。你们能够看到，这个系统没有用户注册、登陆的业务，而是简单的采用AccessCode来让用户访问本身的数据，由于这是一个学习案例。我之因此选择这个案例来进行分析，就是由于你们通常对电子商务系统的业务相对比较熟悉，这样咱们讨论就有了必定的基础。下一篇文章，我想从DDD的角度，分析如何进行战略设计（划分子域以及BC）和战术设计（创建领域模型）。