像梦一样奔驰|谈DDD领域驱动设计和建模( 二 ) 作者：人月神话

基础设施层：本层作为其他层的支撑库存在。它提供了层间的通信,实现对业务对象的持久化,包含对用户界面层的支撑库等作用。

对于领域在这里我更愿意将其理解为业务领域，领域的表现是一系列存在相关关联和依赖关系的业务实体对象表现出现的业务行为的一个合集。
传统的用例驱动往往我们会先分析会有哪些业务行为和业务操作，再来分析这些行为操作的承载对象，如RUP中的实体类控制类等。领域驱动的方法则可能是尽快先找出核心的业务实体对象，再通过交互分析来分析对象应该展现出来的行为。
在解耦的层面我们看到两个层面的解耦：
第一个层面是业务操作和业务实体的解耦，这也是传统的SOA的一个思想，在领域建模里面可以看到分解为业务服务，实体对象和值对象等。
第二个层面则是应用功能，服务能力，基础设施三层的解耦，在领域驱动设计的分层架构中则将其分解为了应用层，领域层，基础设施层。基础设施层提供资源层和持久化的能力，领域层提供业务服务能力，而应用层仅仅处理能力的协同，状态保存，服务的编排问题等。

领域驱动设计中领域层的构建可以是整个系统构建的核心，通过领域层的构建再拓展到持久化层和界面展现层。领域模型完全基于面向对象思路构建，因此完全可以兼顾底层是关系型数据库还是NoSQL数据库来持久化。而且领域模型的持久化好像专门就是为适合NoSQL数据库而设计。对于界面展现层相同的道理，领域层只是提供和暴露业务服务，具体业务服务如何交互，协同和展现并不是关键。
一个完整的领域层应该包括了实体对象，值对象，主域模型类，业务服务类几个关键的类。
实体对象有唯一的标识符，需要持久化，对应现实中的业务对象，而值对象无唯一标识符，仅仅关注它拥有的一组属性。实体对象本身会表现出对应到行为，而值对象仅仅是属性的结合。在多个实体对象上层可能还要构建主域层对象，程度跨多个实体对象的操作组合。而对于业务服务仅仅是能力通过接口方式的暴露。一方面是实现应用层到领域层的协同，一方面是实现多个domain主域间的协同。
对于领域层，在大型系统构建过程中可以是首先进行全局的领域层建模再划分为多个domain域，形成业务组件或模块。也可以首先进行业务主体域的划分，然后再分解下去后识别每个业务域里面的实体对象和表现行为。组件划分思路需要引入到大型领域层的构建。即领域层也会组件化和模块化。业务服务即需要考虑模块内，也需要考虑模块间协同。在这里可以看到是领域层本身进行模块化后引入的，对业务服务的能力进行了扩展。
领域驱动设计让我们在分析和构建一个应用系统的时候，真正的转正核心矛盾，即领域对象和行为表现，而不是太多的关注基础设施和持久化机制，不去关心前台的展现层技术等。因为只有领域层这块在各种技术架构中是完全可以复用的，也是业务系统的核心。我们谈业务架构驱动应用架构，而业务架构核心内容就应该体现到应用架构的领域层模型中。
领域模型关键对象和UML彩色建模领域驱动设计实质是业务场景和实体驱动的设计，有关注业务场景和流程，分析，识别和抽象业务对象，进一步分析对象间的创建，关联，逻辑和服务。注意领域模型和多层架构和技术关联很小，更多的是关注概念模型和业务逻辑，因此抛开了多层架构和框架本身，先研究领域模型再由内而外过渡到数据层和界面层，以及多层的集成。按照Eric的表述，将领域中的组成角色分为五种：