前言
ENode是一个应用开发框架。通过ENode，我们可以方便的开发基于DDD+CQRS+EventSourcing+EDA架构的应用程序。之前我已经写了很多关于ENode的架构以及设计原理的文章，但是因为没有和具体的例子结合来进行分析，所以可能很多人还是无法理解ENode的功能和设计。所以，接下来，我想通过一个较为完整的案例来一步步从业务分析到领域模型设计再到代码实现，以案例的方式讲解ENode如何帮助我们落实DDD的编码实现。
本文是这个系列的第一篇，所以需要先介绍这个案例的一些业务。
前段时间，我用业余时间开发了一个DDD的案例，叫Conference。它是一个支持多租户的会议管理和预定的系统。这个项目不是我个人想出来的，而是微软的一个CQRS实践的一个开源项目，项目主页：http://cqrsjourney.github.io/
Conference业务简介
Conference是这样一个系统，它提供了一个在线创建会议以及预订会议座位的平台。这个系统的用户有两类：1）客户，可以创建和管理会议；2）会议座位预定者，可以预订会议座位。具体的关键业务描述如下：
- 客户创建一个会议，并录入会议的基本信息，比如名称、时间段、地点，等；会议创建后，系统会为客户自动生成一个AccessCode，客户可以通过AccessCode访问自己创建的会议；
- 客户定义某个会议的座位类型，可以定义多个，每个座位类型包含的信息有：名称、座位价格、座位数量；
- 客户发布或取消发布某个会议，当一个会议发布后，预订者就可以在线预订会议的座位了；如果取消发布，则该会议对预订者不可见；只有未发布状态的会议才能修改；
- 预订者在预订会议座位时，会生成订单，订单需要进行支付才会生效；
- 订单生成后，预订者可以有15分钟的时间付款，超过15分钟，订单预定的座位就会回收，允许其他人预定；
- 订单生成后，系统会为预订者生成一个AccessCode，用户可以通过AccessCode查看自己的订单；
- 预订者成功预订了座位后，可以指定每个座位的实际参会人信息；
- 客户（会议的Owner）可以管理他创建的每个会议的所有订单，比如可以查看该会议的所有订单以及参会人信息，以方便联系参会人；
结束语
通过上面的业务介绍，我们不难理解，这个系统本质是一个简易的电子商务系统。它提供了商品管理、下订单、支付三大功能。大家可以看到，这个系统没有用户注册、登录的业务，而是简单的采用AccessCode来让用户访问自己的数据，因为这是一个学习案例。我之所以选择这个案例来进行分析，就是因为大家一般对电子商务系统的业务相对比较熟悉，这样我们讨论就有了一定的基础。下一篇文章，我想从DDD的角度，分析如何进行战略设计（划分子域以及BC）和战术设计（建立领域模型）。
