谈领域驱动的设计

最近一直在学习领域驱动设计，发现领域驱动设计的核心仍然是传统的面向对象分析设计的思路，但是却可以很好的和现有的组件化架构，分层架构，SOA服务等相关内容更好的融合。对于传统的EA企业架构分析在分解到最底层的时候，很适合自然过渡到领域驱动设计的思路上来。另外对于现有的基于NoSQL数据库的信息系统开发，领域驱动设计更是必须具备的系统分析和建模思路。

领域在这里我更愿意将其理解为业务领域，领域的表现是一系列存在相关关联和依赖关系的业务实体对象表现出现的业务行为的一个合集。传统的用例驱动往往我们会先分析会有哪些业务行为和业务操作，再来分析这些行为操作的承载对象，如RUP中的实体类控制类等。领域驱动的方法则可能是尽快先找出核心的业务实体对象，再通过交互分析来分析对象应该展现出来的行为。

在解耦的层面我们看到两个层面的解耦，首先是业务操作和业务实体的解耦，这也是传统的SOA的一个思想，在领域建模里面可以看到分解为业务服务，实体对象和值对象等。第二个层面则是应用功能，服务能力，基础设施三层的解耦，在领域驱动设计的分层架构中则将其分解为了应用层，领域层，基础设施层。基础设施层提供资源层和持久化的能力，领域层提供业务服务能力，而应用层仅仅处理能力的协同，状态保存，服务的编排问题等。

领域驱动设计中领域层的构建可以是整个系统构建的核心，通过领域层的构建再拓展到持久化层和界面展现层。领域模型完全基于面向对象思路构建，因此完全可以兼顾底层是关系型数据库还是NoSQL数据库来持久化。而且领域模型的持久化好像专门就是为适合NoSQL数据库而设计。对于界面展现层相同的道理，领域层只是提供和暴露业务服务，具体业务服务如何交互，协同和展现并不是关键。

一个完整的领域层应该包括了实体对象，值对象，主域模型类，业务服务类几个关键的类。实体对象有唯一的标识符，需要持久化，对应现实中的业务对象，而值对象无唯一标识符，仅仅关注它拥有的一组属性。实体对象本身会表现出对应到行为，而值对象仅仅是属性的结合。在多个实体对象上层可能还要构建主域层对象，程度跨多个实体对象的操作组合。而对于业务服务仅仅是能力通过接口方式的暴露。一方面是实现应用层到领域层的协同，一方面是实现多个domain主域间的协同。

对于领域层，在大型系统构建过程中可以是首先进行全局的领域层建模在划分为多个domain域，形成业务组件或模块。也可以首先进行业务主体域的划分，然后再分解下去后识别每个业务主题域里面的实体对象和表现行为。组件划分思路需要引入到大型领域层的构建。即领域层也会组件化和模块化。业务服务即需要考虑模块内，也需要考虑模块间协同。在这里可以看到是领域层本身进行模块化后引入的，对业务服务的能力进行了扩展。

领域驱动设计让我们在分析和构建一个应用系统的时候，真正的转正核心矛盾，即领域对象和行为表现，而不是太多的关注基础设施和持久化机制，不去关心前台的展现层技术等。因为只有领域层这块在各种技术架构中是完全可以复用的，也是业务系统的核心。我们谈业务架构驱动应用架构，而业务架构核心内容就应该体现到应用架构的领域层模型中。

对于实体(Entities)，值对象(Value objects)，工厂(Factories)，仓库(Repositories)和服务(Services)的关系再做一个理解如下。工厂(Factories)完成实体对象的实例化并通过服务接口传递到展现层面和应用层，而仓库(Repositories)则是和基础设施层接口，实现实例化对象后的持久化问题。

对于聚合，其核心即是多个实体对象是否是共同的生命周期存在，如果是的话则一定有一个聚合根，没有根存在了下面的子节点也将消亡。如客户，客户银行账户是聚合关系。订单，订购明细记录是聚合关系。这些虽然在存储的时候可能是多张数据表，但是在对象的管理上往往是当做一个完整业务实体对象在管理。