领域驱动设计（转）

---

介绍

引言

软件系统面向对象的设计思想可谓历史悠久，20世纪70年代的Smalltalk可以说是面向对象语言的经典，直到今天我们依然将这门语言视为面向对象语言的基础。随着编程语言和技术的发展，各种语言特性层出不穷，面向对象是大部分语言的一个基本特性，像C++、Java、C#这样的静态语言，Ruby、Python这样的动态语言都是面向对象的语言。

但是面向对象语言并不是银弹，如果开发人员认为使用面向对象语言写出来的程度本身就是面向对象的，那就大错特错了。实际开发中，大量的业务逻辑堆积在一个巨型类中的例子屡见不鲜，代码的复用性和扩展性无法得到保证。为了解决这样的问题，领域驱动设计提出了清晰的分层架构和领域对象的概念，让面向对象的分析和设计进入了一个新的阶段，对企业级软件开发起到了巨大的推动作用。
本文主要介绍了领域驱动设计的基本概念、要素、特点，最后介绍了我们在软件开发过程中的领域驱动设计实践。

什么是领域驱动设计（DDD）

2004年著名建模专家Eric Evans发表了他最具影响力的书籍:《Domain-Driven Design: Tackling Complexity in the Heart of Software》(中文译名：领域驱动设计：软件核心复杂性应对之道)，书中提出了领域驱动设计(简称 DDD)的概念。

领域驱动设计事实上是针对OOAD的一个扩展和延伸，DDD基于面向对象分析与设计技术，对技术架构进行了分层规划，同时对每个类进行了策略和类型的划分。

领域模型是领域驱动的核心。采用DDD的设计思想，业务逻辑不再集中在几个大型的类上，而是由大量相对小的领域对象(类)组成，这些类具备自己的状态和行为，每个类是相对完整的独立体，并与现实领域的业务对象映射。领域模型就是由这样许多的细粒度的类组成。基于领域驱动的设计，保证了系统的可维护性、扩展性和复用性，在处理复杂业务逻辑方面有着先天的优势。

为什么引入领域驱动设计（DDD）

传统设计的缺陷

1. 贫血模型：

   • Model是只有getter/setter方法的贫血模型，仅仅成为一个数据载体，而业务方法分散在各个分层中。
   • 贫血模型导致软件难以扩展和维护，违背OO思想，重新回到面向过程的编程老路。开发效率不高。

2. 面向数据库设计：

   • 不利于进行OO设计和分析，仍然是面向过程的拼装
   • 对象建模不准确，直接影响到对业务的正确把握和扩展
   • 数据库中建立了不少的存储过程和触发器来处理业务，依赖于某种数据库特定的功能和函数
3. 业务信息化困境：
   
   • IT人员与业务人员之间沟通成本高昂
   • 业务逻辑分散，业务难以重用
   • 业务和具体框架耦合，难以适应未来变化

---

领域通用语言

领域驱动设计的一个核心的原则是使用一种基于模型的语言。因为模型是软件满足领域的共同点，它很适合作为这种通用语言的构造基础。使用模型作为语言的核心骨架，要求团队在进行所有的交流是都使用一致的语言，在代码中也是这样。在共享知识和推敲模型时，团队会使用演讲、文字和图形。这儿需要确保团队使用的语言在所有的交流形式中看上去都是一致的，这种语言被称为”通用语言（Ubiquitous Language）”。通用语言应该在建模过程中广泛尝试以推动软件专家和领域专家之间的沟通，从而发现要在模型中使用的主要的领域概念。

将领域模型转换为代码实现的最佳选择

拥有一个看上去正确的模型不代表模型能被直接转换成代码，也或者它的实现可能会违背某些我们所不建议的软件设计原则。我们该如何实现从模型到代码的转换，并让代码具有可扩展性、可维护性，高性能等指标呢？另外，如实反映领域的模型可能会导致对象持久化的一系列问题，或者导致不可接受的性能问题。那么我们应该怎么做呢？

领域建模时思考问题的角度

“用户需求”不能等同于”用户”，捕捉”用户心中的模型”也不能等同于”以用户为核心设计领域模型”。《老子》书中有个观点：有之以为利，无之以为用。在这里，有之利，即建立领域模型；无之用，即包容用户需求。举些例子，一个杯子要装满一杯水，我们在制作杯子时，制作的是空杯子，即要把水倒出来，之后才能装下水；再比如，一座房子要住人，我们在建造房子时，建造的房子是空的，唯有空的才能容纳人的居住。因此，建立领域模型时也要将用户置于模型之外，这样才能包容用户的需求。

所以，我的理解是：我们设计领域模型时不能以用户为中心作为出发点去思考问题，不能老是想着用户会对系统做什么；而应该从一个客观的角度，根据用户需求挖掘出领域内的相关事物，思考这些事物的本质关联及其变化规律作为出发点去思考问题。

领域模型是排除了人之外的客观世界模型，但是领域模型包含人所扮演的参与者角色，但是一般情况下不要让参与者角色在领域模型中占据主要位置，如果以人所扮演的参与者角色在领域模型中占据主要位置，那么各个系统的领域模型将变得没有差别，因为软件系统就是一个人机交互的系统，都是以人为主的活动记录或跟踪；比如：论坛中如果以人为主导，那么领域模型就是：人发帖，人回帖，人结贴，等等；DDD的例子中，如果是以人为中心的话，就变成了：托运人托运货物，收货人收货物，付款人付款，等等；因此，当我们谈及领域模型时，已经默认把人的因素排除开了，因为领域只有对人来说才有意义，人是在领域范围之外的，如果人也划入领域，领域模型将很难保持客观性。领域模型是与谁用和怎样用是无关的客观模型。归纳起来说就是，领域建模是建立虚拟模型让我们现实的人使用，而不是建立虚拟空间，去模仿现实。

以Eric Evans（DDD之父）在他的书中的一个货物运输系统为例子简单说明一下。在经过一些用户需求讨论之后，在用户需求相对明朗之后，Eric这样描述领域模型：

一个Cargo（货物）涉及多个Customer（客户，如托运人、收货人、付款人），每个Customer承担不同的角色；

Cargo的运送目标已指定，即Cargo有一个运送目标；

从上面的描述我们可以看出，他完全没有从用户的角度去描述领域模型，而是以领域内的相关事物为出发点，考虑这些事物的本质关联及其变化规律的。上述这段描述完全以货物为中心，把客户看成是货物在某个场景中可能会涉及到的关联角色，如货物会涉及到托运人、收货人、付款人；货物有一个确定的目标，货物会经过一系列列的运输动作到达目的地；其实，我觉得以用户为中心来思考领域模型的思维只是停留在需求的表面，而没有挖掘出真正的需求的本质；我们在做领域建模时需要努力挖掘用户需求的本质，这样才能真正实现用户需求；

关于用户、参与者这两个概念的区分，可以看一下下面的例子：

试想两个人共同玩足球游戏，操作者（用户）是驱动者，它驱使足球比赛领域中，各个"人"（参与者）的活动。这里立下一个假设，假设操作者A操作某一队员a，而队员a拥有着某人B的信息，那么有以下说法，a是B的镜像，a是领域参与者，A是驱动者。 

如果不使用DDD？

面对复杂的业务场景和需求，如果没有建立和实现领域模型，会导致应用架构出现胖服务层和贫血的领域模型，在这样的架构中，Service层开始积聚越来越多的业务逻辑，领域对象则成为只有getter和setter方法的数据载体。这种做法还会导致领域特定业务逻辑和规则散布于多个的Service类中，有些情况下还会出现重复的逻辑。我们曾经见过5000多行的Service类，上百个方法，代码基本上是不可读的。

在大多数情况下，贫血的领域模型没有成本效益。它们不会给公司带来超越其它公司的竞争优势，因为在这种架构里要实现业务需求变更，开发并部署到生产环境中去要花费太长的时间。

领域模型是很重要的

领域驱动设计告诉我们，在通过软件实现一个业务系统时，建立一个领域模型是非常重要和必要的，因为领域模型具有以下特点：

• 领域模型是对具有某个边界的领域的一个抽象，反映了领域内用户业务需求的本质；领域模型是有边界的，只反应了我们在领域内所关注的部分；
• 领域模型只反映业务，和任何技术实现无关；领域模型不仅能反映领域中的一些实体概念，如货物，书本，应聘记录，地址，等；还能反映领域中的一些过程概念，如资金转账，等；
• 领域模型确保了我们的软件的业务逻辑都在一个模型中，都在一个地方；这样对提高软件的可维护性，业务可理解性以及可重用性方面都有很好的帮助；
• 领域模型能够帮助开发人员相对平滑地将领域知识转化为软件构造；
• 领域模型贯穿软件分析、设计，以及开发的整个过程；领域专家、设计人员、开发人员通过领域模型进行交流，彼此共享知识与信息；因为大家面向的都是同一个模型，所以可以防止需求走样，可以让软件设计开发人员做出来的软件真正满足需求；
• 要建立正确的领域模型并不简单，需要领域专家、设计、开发人员积极沟通共同努力，然后才能使大家对领域的认识不断深入，从而不断细化和完善领域模型；
• 为了让领域模型看的见，我们需要用一些方法来表示它；图是表达领域模型最常用的方式，但不是唯一的表达方式，代码或文字描述也能表达领域模型；
• 领域模型是整个软件的核心，是软件中最有价值和最具竞争力的部分；设计足够精良且符合业务需求的领域模型能够更快速的响应需求变化；

优势特点

• 领域驱动的核心应用场景就是解决复杂业务的设计问题，其特点与这一核心主题息息相关：
  
  1. 统一语言：项目中所有人统一交流语言，避免过多的技术化词语，比如dao等。
  2. 统一领域模型：业务专家与IT人员统一使用一种模型，没有数据库、数据表等专业软件技术的干扰。
  3. 专有的领域层：领域层除了业务以外，没有软件架构，框架等底层技术。
  4. 领域层代码即业务文档，是企业最核心的业务价值。
  5. 分层架构与职责划分：领域驱动设计很好的遵循了关注点分离的原则，提出了成熟、清晰的分层架构。同时对领域对象进行了明确的策略和职责划分，让领域对象和现实世界中的业务形成良好的映射关系，为领域专家与开发人员搭建了沟通的桥梁。
  6. 复用：在领域驱动设计中，领域对象是核心，每个领域对象都是一个相对完整的内聚的业务对象描述，所以可以形成直接的复用。同时设计过程是基于领域对象而不是基于数据库的Schema，所以整个设计也是可以复用的。

DDD通常适用于具备复杂业务逻辑的软件系统，对软件的可维护性和扩展性要求比较高。不适用简单的增删改查业务。

• 为什么面向对象比面向过程更能适应业务变化

  对象将需求用类一个个隔开，就像用储物箱把东西一个个封装起来一样，需求变了，分几种情况，最严重的是大变，那么每个储物箱都要打开改，这种方法就不见得有好处；但是这种情况发生概率比较小，大部分需求变化都是局限在一两个储物箱中，那么我们只要打开这两个储物箱修改就可以，不会影响其他储物柜了。

  而面向过程是把所有东西都放在一个大储物箱中，修改某个部分以后，会引起其他部分不稳定，一个BUG修复，引发新的无数BUG，最后程序员陷入焦头烂额，如日本东京电力公司员工处理核危机一样，心力交瘁啊。

  所以，我们不能粗粒度看需求变，认为需求变了，就是大范围变，万事万物都有边界，老子说，无欲观其缴，什么事物都要观察其边界，虽然需求可以用”需求”这个名词表达，谈到需求变了，不都意味着最大边界范围的变化，这样看问题容易走极端。

  其实就是就地画圈圈——边界。我们小时候写作文分老三段也是同样道理，各自职责明确，划分边界明确，通过过渡句实现承上启下——接口。为什么组织需要分不同部门，同样是边界思维。画圈圈容易，但如何画才难，所以OO中思维非常重要。

  需求变化所引起的变化是有边界，若果变化的边界等于整个领域，那么已经是完全不同的项目了。要掌握边界，是需要大量的领域知识的。否则，走进银行连业务职责都分不清的，如何画圈圈呢？

  面向过程是无边界一词的（就算有也只是最大的边界），它没有要求各自独立，它可以横跨边界进行调用，这就是容易引起BUG的原因，引起BUG不一定是技术错误，更多的是逻辑错误。分别封装就是画圈圈了，所有边界都以接口实现。不用改或者小改接口，都不会牵一发动全身。若果面向过程中考虑边界，那么也就已经上升到OO思维，即使用的不是对象语言，但对象已经隐含其中。说白了，面向对象与面向过程最大区别就是：分解。边界的分解。从需求到最后实现都贯穿。

  面向对象的实质就是边界划分，封装，不但对需求变化能够量化，缩小影响面；因为边界划分也会限制出错的影响范围，所以OO对软件后期BUG等出错也有好处。

  软件世界永远都有BUG,BUG是清除不干净的，就像人类世界永远都存在不完美和阴暗面，问题关键是：上帝用空间和时间的边界把人类世界痛苦灾难等不完美局限在一个范围内；而软件世界如果你不采取OO等方法进行边界划分的话，一旦出错，追查起来情况会有多糟呢？

---

• DDD与数据库设计区别
  
  1. 领域驱动设计是一种面向对象的设计。
  2. 领域驱动设计主要基于现实业务中的模型，更加贴近真实业务。
  3. 领域驱动设计的产出品——领域对象（Domain Object）是一个”充血模型”，不但包含业务对象的属性，也包含对象的业务方法和行为。
  4. 领域驱动设计并不关心数据库，而是与领域专家一起，采用统一的语言分析领域对象的属性，业务方法，以及领域对象之间的关系，并为之建模。
  5. 领域驱动设计能够有效的减少沟通成本。

---

分层架构

DDD是一种设计思想，它本身不绑定到任何一种具体的架构风格，可以应用在多种不同的架构风格中。本文探讨在经典的分层架构中如何应用DDD，以及在DDD的语境下，分层结构每一层的具体职责。

分层架构是企业应用开发中采用率非常高的一种架构风格。它将软件系统的不同职责划分到不同的逻辑层中，并严格定义这些逻辑层的调用顺序。

在《领域驱动设计——软件核心复杂性的应对之道》一书中，DDD范式的创始人Evans提出下图所示的这样一种分层架构：

整个系统划分为基础设施层（Infrastructure）、领域层（Domain）、应用层（Application）和用户接口层（User Interface，也称为表示层）。下面从各个维度分别讨论之。

领域层（Domain Layer）

领域层实现业务逻辑。

什么是业务逻辑？业务逻辑就是存在于问题域即业务领域中的实体、概念、规则和策略等，与软件实现无关，主要包含下面的内容：

• 业务实体（领域对象）。例如银行储蓄领域中的账户、信用卡等等业务实体。
• 业务规则。例如借记卡取款数额不得超过账户余额，信用卡支付不得超过授信金额，转账时转出账户余额减少的数量等于转入账户余额增加的数量，取款、存款和转账必须留下记录，等等。
• 业务策略。例如机票预订的超订策略（卖出的票的数量稍微超过航班座位的数量，以防有些旅客临时取消登机导致座位空置）等。
• 完整性约束。例如账户的账号不得为空，借记卡余额不得为负数等等。本质上，完整性约束是业务规则的一部分。
• 业务流程。例如，”在线订购”是一个业务流程，它包括”用户登录-选择商品-结算-下订单-付款-确认收货”这一系列流程。

对领域层的进一步说明如下：

• 领域层映射到领域模型，是问题域的领域模型在软件中的反映。
• 包含实体、值对象和领域服务等领域对象，通常这些领域对象和问题域中的概念实体一一对应，具有相同或相似的属性和行为。
• 在实体、值对象和领域服务等领域对象的方法中封装实现业务规则和保证完整性约束（这一点是与CRUD模式相比最明显的差别，CRUD中的领域对象没有行为）。
• 领域对象在实现业务逻辑上具备坚不可摧的完整性，意味着不管外界代码如何操作，都不可能创建不合法的领域对象（例如没有账户号码或余额为负数的借记卡对象），亦不可能打破任何业务规则（例如在多次转账之后，钱凭空丢失或凭空产生）。
• 领域对象的功能是高度内聚的，具有单一的职责，任何不涉及业务逻辑的复杂的组合操作都不在领域层而在应用层中实现。
• 领域层中的全部领域对象的总和在功能上是完备的，意味着系统的所有行为都可以由领域层中的领域对象组合实现。

应用层（Application Layer）

应用层定义系统功能，并指挥领域层中的领域对象实现这些功能。
应用层是整个系统的功能外观，封装了领域层的复杂性并隐藏了其内部实现机制。

• 应用层映射到系统用例模型，是系统用例模型在软件中的反映。
• 应用层接口描述了系统的全部功能，意味着系统用例模型中的所有用例都可以在应用层接口中找到对应的方法。
• 应用层实现类不实现业务逻辑，它通过排列组合领域层的领域对象来实现用例，它的职责可表示为”编排和转发”，即将它要实现的功能委托给一个或多个领域对象来实现，它本身只负责安排工作顺序和拼装操作结果。

基础设施层（Infrastructure Layer）

基础设施层为其余各层提供技术支持。

基础设施层是系统中的技术密集部分。它为领域层、应用层的业务服务（例如持久化、消息通信等等）提供具体的技术支持，用户接口层通常使用特定的表示层框架（例如SpringMVC、Struts或Tapestry）实现，但有需要时也可以申请技术设施层提供专门的技术支持。

一些例子：

• 领域层需要持久化服务，在DDD中，领域层通过仓储（Repository）接口定义持久化需求，基础设施层通过采用JDBC、JPA、Hibernate、NoSQL等技术之一实现领域层的仓储接口，为领域层提供持久化服务。
• 领域层需要消息通知服务，在领域层中定义了一个NotificationService领域服务接口，基础设施层通过采用手机短信、电子邮件、Jabber等技术实现NotificationService领域服务接口，为领域层提供消息通知服务。
• 用户接口层需要一个对象序列化服务，将任何JavaBean序列化为JSON字符串，可以在用户接口层定义一个ObjectSerializer服务接口，基础设施层通过采用Gson实现这一接口，为用户接口层提供对象序列化服务。

以上例子都是满足依赖倒置原则，通过控制反转的方式为高层模块提供低层服务，在实践中，可以通过Spring等IoC容器将基础设施层的实现类实例进行依赖注入。
基础设施层的典型实现形式是提供一个一个的类，这些类使用某些专有的技术实现其余各层（主要是领域层）定义的接口，例如提供一个领域层的仓储接口的实现类，使用Hibernate实现持久化，以及提供领域层的通知接口的实现类，使用ActiveMQ广播领域层中发生的事件，等等。

基础设施层也被称为数据源层或数据访问层。这些名称的一个缺点是给读者一个强烈的暗示：基础设施层只负责数据库访问。虽然数据库访问是基础设施层的职责之一，但基础设施层的负责范围比单纯数据库访问宽广的多，它实现了系统的全部技术性需求，例如上面例子中的通知服务和对象序列化服务，等等。

用户接口层（User Interface）

用户接口层为外部用户访问底层系统提供访问界面和数据表示。

用户接口层在底层系统之上封装了一层可访问外壳，为特定类型的外部用户（人或计算机程序）访问底层系统提供访问入口，并将底层系统的状态数据以该类型客户需要的形式呈现给它们。

用户接口层有两个任务：（1）从用户处接收命令操作，改变底层系统状态；（2）从用户处接收查询操作，将底层系统状态以合适的形式呈现给用户。

说明：

• 典型的用户是人类用户，但是也可能是别的计算机系统。例如如果ERP系统要访问我们的系统获取信息，它也是一种用户。
• 不同类型的用户需要不同形式的用户接口，例如为人类用户提供Web界面和手机App，为ERP软件用户提供REST服务接口。
• 不同类型的用户需要不同形式的数据表示，包括表现形式的不同（XML、JSON、HTML）和内容的不同（例如手机App中呈现的数据内容往往比Web页面中呈现的少）。
• 用户接口层对应用层进行封装，用户接口层的操作与应用层上定义的操作通常是一一对应的关系。用户接口层从外部用户处接受输入，转换成应用层方法的参数形式，调用应用层方法将任务交由底层系统执行，并将返回结果转换成合适的形式返回给外部用户。
• 用户界面层的典型任务是下面三个：校验——校验外部客户输入的数据是否合法；转换——将外部客户的输入转换成对底层系统的方法调用参数，以及将底层系统的调用结果转换成外部客户需要的形式；转发——将外部客户的请求转发给底层系统。

用户接口层也被称为用户界面层或表示层。

有时候，为了某些需要，我们可以从用户接口层中分离出一个亚层，可命名为 门面层（Facade）。位于真正的用户接口层和应用层之间。

门面层（Facade Layer）

门面层隔离前台和后台系统，定义特定于用户接口层的数据结构，从后台获取数据内容并转化为用户接口层的数据形式。

从用户接口层中分离出专门的门面层，具有下面的优势：

• 使得用户接口层能够独立于后台系统，与后台系统并行开发。

  用户接口层通过门面层接口与应用层和领域层解耦，意味着用户接口层可以独立开发，不必等待后台系统的完成，亦不受后台系统重构的影响，在需求调研阶段系统原型出来并得到用户确认之后，就可以开始用户接口层的开发了。可以根据界面原型定义用户接口层需要的数据结构，该数据结构与底层数据结构解耦，不需要知道底层数据类型和数据之间的关联关系。将底层数据和界面数据连接起来并相互转换是门面层实现类的职责，这方面工作可以等待前后台系统分别完成之后进行。

• 使得分布式部署成为可能。

  如果没有门面层的隔离，用户接口层只能直接使用领域层的领域对象作为自己的数据展现结构。这样我们就不能将系统进行分布式部署，将用户接口层和后台系统（领域层、应用层等）分别部署到不同的服务器上。因为在JPA和Hibernate等技术实现中，领域实体绑定到当前服务器的持久化上下文中，必须脱管之后才能够跨越JVM进行传输。更大的问题是事务问题，事务要跨越服务器的边界，复杂性增加，性能严重下降。门面层的存在使得实体和事务都限制在后台系统，不需要扩展到前台服务器。

• 避免Hibernate中”会话已关闭”的问题，消除成本巨大的”Open Session in View”模式的需要。

  在采用JPA或Hibernate作为持久化手段的系统中存在臭名昭著的”会话已关闭”问题，对付这一问题的主要手段是Open Session in View这一存在潜在性能问题的方案。如果不采用门面层隔离后台数据结构，在前端展现数据需要访问实体的延迟初始化属性时就会遇到”会话已关闭”问题，而采用Open Session in View模式处理这个问题就意味着事务不是在后端完成而是扩展到前端用户接口层，在大访问量的网站上会遭遇严重的性能问题并降低吞吐量。采用门面模式的话，有关联关系的数据在后台拼装完毕再一次性返回给前端，事务局限在后端范围，不再有”会话已关闭”和性能问题。

门面层说明：

• 门面层特定于用户接口层，由用户接口层定义和控制（包括操作和数据的形式和内容），这意味着需要为不同类型的用户接口层开发专门的门面层。
• 查询结果通常以数据传输对象（DTO）的形式表示。DTO的结构由用户接口层而不是后端决定，代表前端需要的数据形式，与底层数据结构脱耦。
• 通过门面层实现类访问后端的应用层。实现类将后端数据拼装为DTO并返回给前端，它可以将数据装配职责委托给专门的Assembler工具类去执行。
• 在分布式系统中，可以在前端和后端分别部署门面层。前后端的门面层接口相同，但后端的门面层实现类负责数据装配和发布，前端的门面层实现类负责通过某种通信机制（Web Service等）与后端门面层通讯，获取后者装配好的数据。传输过程中DTO可能序列化为JSON或XML等形式。

---

构造块

总览图

关联

关联本身不是一个模式，但它在领域建模的过程中非常重要，所以需要在探讨各种模式之前，先讨论一下对象之间的关联该如何设计。我觉得对象的关联的设计可以遵循如下的一些原则：
关联尽量少，对象之间的复杂的关联容易形成对象的关系网，这样对于我们理解和维护单个对象很不利，同时也很难划分对象与对象之间的边界；另外，同时减少关联有助于简化对象之间的遍历；

对多的关联也许在业务上是很自然的，通常我们会用一个集合来表示1对多的关系。但我们往往也需要考虑到性能问题，尤其是当集合内元素非常多的时候，此时往往需要通过单独查询来获取关联的集合信息；

关联尽量保持单向的关联；

在建立关联时，我们需要深入去挖掘是否存在关联的限制条件，如果存在，那么最好把这个限制条件加到这个关联上；往往这样的限制条件能将关联化繁为简，即可以将多对多简化为1对多，或将1对多简化为1对1；

实体（Entity）

实体:具备唯一ID，能够被持久化，具备业务逻辑，对应现实世界业务对象 。

因为我们有时需要区分是哪个实体。有两个实体，如果唯一标识不一样，那么即便实体的其他所有属性都一样，我们也认为他们两个不同的实体；因为实体有生命周期，实体从被创建后可能会被持久化到数据库，然后某个时候又会被取出来。所以，如果我们不为实体定义一种可以唯一区分的标识，那我们就无法区分到底是这个实体还是哪个实体。

另外，不应该给实体定义太多的属性或行为，而应该寻找关联，发现其他一些实体或值对象，将属性或行为转移到其他关联的实体或值对象上。比如Customer实体，他有一些地址信息，由于地址信息是一个完整的有业务含义的概念，所以，我们可以定义一个Address对象，然后把Customer的地址相关的信息转移到Address对象上。如果没有Address对象，而把这些地址信息直接放在Customer对象上，并且如果对于一些其他的类似Address的信息也都直接放在Customer上，会导致Customer对象很混乱，结构不清晰，最终导致它难以维护和理解；

值对象（Value Object）

值对象：不具有唯一ID，由对象的属性描述，一般为内存中的临时对象，可以用来传递参数或对实体进行补充描述

在领域中，并不是没一个事物都必须有一个唯一标识，也就是说我们不关心对象是哪个，而只关心对象是什么。就以上面的地址对象Address为例，如果有两个Customer的地址信息是一样的，我们就会认为这两个Customer的地址是同一个。也就是说只要地址信息一样，我们就认为是同一个地址。用程序的方式来表达就是，如果两个对象的所有的属性的值都相同我们会认为它们是同一个对象的话，那么我们就可以把这种对象设计为值对象。因此，值对象没有唯一标识，这是它和实体的最大不同。另外值对象在判断是否是同一个对象时是通过它们的所有属性是否相同，如果相同则认为是同一个值对象；而我们在区分是否是同一个实体时，只看实体的唯一标识是否相同，而不管实体的属性是否相同；值对象另外一个明显的特征是不可变，即所有属性都是只读的。因为属性是只读的，所以可以被安全的共享；当共享值对象时，一般有复制和共享两种做法，具体采用哪种做法还要根据实际情况而定；另外，我们应该给值对象设计的尽量简单，不要让它引用很多其他的对象，因为他只是一个值，就像int a = 3;那么”3”就是一个我们传统意义上所说的值，而值对象其实也可以和这里的”3”一样理解，也是一个值，只不过是用对象来表示。所以，当我们在C#语言中比较两个值对象是否相等时，会重写GetHashCode和Equals这两个方法，目的就是为了比较对象的值；值对象虽然是只读的，但是可以被整个替换掉。就像你把a的值修改为”4”(a = 4;)一样，直接把”3”这个值替换为”4”了。值对象也是一样，当你要修改Customer的Address对象引用时，不是通过Customer.Address.Street这样的方式来实现，因为值对象是只读的，它是一个完整的不可分割的整体。我们可以这样做：Customer.Address = new Address(…);

领域服务（Domain Service）

领域服务：为上层建筑提供可操作的接口，负责对领域对象进行调度和封装，同时可以对外提供各种形式的服务

领域中的一些概念不太适合建模为对象，即归类到实体对象或值对象，因为它们本质上就是一些操作，一些动作，而不是事物。这些操作或动作往往会涉及到多个领域对象，并且需要协调这些领域对象共同完成这个操作或动作。如果强行将这些操作职责分配给任何一个对象，则被分配的对象就是承担一些不该承担的职责，从而会导致对象的职责不明确很混乱。但是基于类的面向对象语言规定任何属性或行为都必须放在对象里面。所以我们需要寻找一种新的模式来表示这种跨多个对象的操作，DDD认为服务是一个很自然的范式用来对应这种跨多个对象的操作，所以就有了领域服务这个模式。和领域对象不同，领域服务是以动词开头来命名的，比如资金转帐服务可以命名为MoneyTransferService。当然，你也可以把服务理解为一个对象，但这和一般意义上的对象有些区别。因为一般的领域对象都是有状态和行为的，而领域服务没有状态只有行为。需要强调的是领域服务是无状态的，它存在的意义就是协调领域对象共完成某个操作，所有的状态还是都保存在相应的领域对象中。我觉得模型（实体）与服务（场景）是对领域的一种划分，模型关注领域的个体行为，场景关注领域的群体行为，模型关注领域的静态结构，场景关注领域的动态功能。这也符合了现实中出现的各种现象，有动有静，有独立有协作。

领域服务还有一个很重要的功能就是可以避免领域逻辑泄露到应用层。因为如果没有领域服务，那么应用层会直接调用领域对象完成本该是属于领域服务该做的操作，这样一来，领域层可能会把一部分领域知识泄露到应用层。因为应用层需要了解每个领域对象的业务功能，具有哪些信息，以及它可能会与哪些其他领域对象交互，怎么交互等一系列领域知识。因此，引入领域服务可以有效的防治领域层的逻辑泄露到应用层。对于应用层来说，从可理解的角度来讲，通过调用领域服务提供的简单易懂但意义明确的接口肯定也要比直接操纵领域对象容易的多。这里似乎也看到了领域服务具有Façade的功能。

说到领域服务，还需要提一下软件中一般有三种服务：应用层服务、领域服务、基础服务。

聚合及聚合根（Aggregate，Aggregate Root）

聚合，它通过定义对象之间清晰的所属关系和边界来实现领域模型的内聚，并避免了错综复杂的难以维护的对象关系网的形成。聚合定义了一组具有内聚关系的相关对象的集合，我们把聚合看作是一个修改数据的单元。

• 特点：

  1. 每个聚合有一个根和一个边界，边界定义了一个聚合内部有哪些实体或值对象，根是聚合内的某个实体；
  2. 聚合内部的对象之间可以相互引用，但是聚合外部如果要访问聚合内部的对象时，必须通过聚合根开始导航，绝对不能绕过聚合根直接访问聚合内的对象，也就是说聚合根是外部可以保持 对它的引用的唯一元素；
  3. 聚合内除根以外的其他实体的唯一标识都是本地标识，也就是只要在聚合内部保持唯一即可，因为它们总是从属于这个聚合的；

• 聚合根负责与外部其他对象打交道并维护自己内部的业务规则；

  1. 基于聚合的以上概念，我们可以推论出从数据库查询时的单元也是以聚合为一个单元，也就是说我们不能直接查询聚合内部的某个非根的对象；
  2. 聚合内部的对象可以保持对其他聚合根的引用；
  3. 删除一个聚合根时必须同时删除该聚合内的所有相关对象，因为他们都同属于一个聚合，是一个完整的概念；

关于如何识别聚合以及聚合根的问题：
我觉得我们可以先从业务的角度深入思考，然后慢慢分析出有哪些对象是：

1. 有独立存在的意义，即它是不依赖于其他对象的存在它才有意义的；
2. 可以被独立访问的，还是必须通过某个其他对象导航得到的；

---

• 如何识别聚合？

  我觉得这个需要从业务的角度深入分析哪些对象它们的关系是内聚的，即我们会把他们看成是一个整体来考虑的；然后这些对象我们就可以把它们放在一个聚合内。所谓关系是内聚的，是指这些对象之间必须保持一个固定规则，固定规则是指在数据变化时必须保持不变的一致性规则。当我们在修改一个聚合时，我们必须在事务级别确保整个聚合内的所有对象满足这个固定规则。作为一条建议，聚合尽量不要太大，否则即便能够做到在事务级别保持聚合的业务规则完整性，也可能会带来一定的性能问题。有分析报告显示，通常在大部分领域模型中，有70%的聚合通常只有一个实体，即聚合根，该实体内部没有包含其他实体，只包含一些值对象；另外30%的聚合中，基本上也只包含两到三个实体。这意味着大部分的聚合都只是一个实体，该实体同时也是聚合根。

• 如何识别聚合根？

  如果一个聚合只有一个实体，那么这个实体就是聚合根；如果有多个实体，那么我们可以思考聚合内哪个对象有独立存在的意义并且可以和外部直接进行交互。

工厂（Factory）

工厂：主要用来创建实体，目前架构实践中一般采用IOC容器来实现工厂的功能

DDD中的工厂也是一种体现封装思想的模式。DDD中引入工厂模式的原因是：有时创建一个领域对象是一件比较复杂的事情，不仅仅是简单的new操作。正如对象封装了内部实现一样（我们无需知道对象的内部实现就可以使用对象的行为），工厂则是用来封装创建一个复杂对象尤其是聚合时所需的知识，工厂的作用是将创建对象的细节隐藏起来。客户传递给工厂一些简单的参数，然后工厂可以在内部创建出一个复杂的领域对象然后返回给客户。领域模型中其他元素都不适合做这个事情，所以需要引入这个新的模式，工厂。工厂在创建一个复杂的领域对象时，通常会知道该满足什么业务规则（它知道先怎样实例化一个对象，然后在对这个对象做哪些初始化操作，这些知识就是创建对象的细节），如果传递进来的参数符合创建对象的业务规则，则可以顺利创建相应的对象；但是如果由于参数无效等原因不能创建出期望的对象时，应该抛出一个异常，以确保不会创建出一个错误的对象。当然我们也并不总是需要通过工厂来创建对象，事实上大部分情况下领域对象的创建都不会太复杂，所以我们只需要简单的使用构造函数创建对象就可以了。隐藏创建对象的好处是显而易见的，这样可以不会让领域层的业务逻辑泄露到应用层，同时也减轻了应用层的负担，它只需要简单的调用领域工厂创建出期望的对象即可。

仓储（Repository）

1. 仓储被设计出来的目的是基于这个原因：领域模型中的对象自从被创建出来后不会一直留在内存中活动的，当它不活动时会被持久化到数据库中，然后当需要的时候我们会重建该对象；重建对象就是根据数据库中已存储的对象的状态重新创建对象的过程；所以，可见重建对象是一个和数据库打交道的过程。从更广义的角度来理解，我们经常会像集合一样从某个类似集合的地方根据某个条件获取一个或一些对象，往集合中添加对象或移除对象。也就是说，我们需要提供一种机制，可以提供类似集合的接口来帮助我们管理对象。仓储就是基于这样的思想被设计出来的；
2. 仓储里面存放的对象一定是聚合，原因是之前提到的领域模型中是以聚合的概念去划分边界的；聚合是我们更新对象的一个边界，事实上我们把整个聚合看成是一个整体概念，要么一起被取出来，要么一起被删除。我们永远不会单独对某个聚合内的子对象进行单独查询或做更新操作。因此，我们只对聚合设计仓储。
3. 仓储还有一个重要的特征就是分为仓储定义部分和仓储实现部分，在领域模型中我们定义仓储的接口，而在基础设施层实现具体的仓储。这样做的原因是：由于仓储背后的实现都是在和数据库打交道，但是我们又不希望客户（如应用层）把重点放在如何从数据库获取数据的问题上，因为这样做会导致客户（应用层）代码很混乱，很可能会因此而忽略了领域模型的存在。所以我们需要提供一个简单明了的接口，供客户使用，确保客户能以最简单的方式获取领域对象，从而可以让它专心的不会被什么数据访问代码打扰的情况下协调领域对象完成业务逻辑。这种通过接口来隔离封装变化的做法其实很常见。由于客户面对的是抽象的接口并不是具体的实现，所以我们可以随时替换仓储的真实实现，这很有助于我们做单元测试。
4. 尽管仓储可以像集合一样在内存中管理对象，但是仓储一般不负责事务处理。一般事务处理会交给一个叫”工作单元（Unit Of Work）”的东西。关于工作单元的详细信息我在下面的讨论中会讲到。
5. 另外，仓储在设计查询接口时，可能还会用到规格模式（Specification Pattern），我见过的最厉害的规格模式应该就是LINQ以及DLINQ查询了。一般我们会根据项目中查询的灵活度要求来选择适合的仓储查询接口设计。通常情况下只需要定义简单明了的具有固定查询参数的查询接口就可以了。只有是在查询条件是动态指定的情况下才可能需要用到Specification等模式。

---

实践

综合说明

• 在四层架构中，领域层和应用层纯粹表达业务意图和机制，不包含任何技术逻辑；而基础设施层和用户接口层纯粹提供技术实现，不包含任何业务逻辑。在业务和技术之间存在清晰的关注点分离。
• 应用层定义系统的全部业务功能，领域层具体实现这些功能。领域层”动于内”，应用层”形诸外”。
• 应用层和领域层合在一起代表了整个业务系统，具备概念上的完整性（包含了全部领域概念，实现了全部的业务行为），但不具备实现上的完整性（没有基础设施层的技术支持，系统不具备可运行性；没有用户接口层支持，系统不具备可访问性）。
• 所有业务逻辑都在领域层实现，业务逻辑泄漏到应用层是一个错误，泄露到基础设施层或用户接口层是严重错误（在用户接口层中实现业务逻辑是采用CRUD模式的常犯的典型错误）。
• 领域层在履行职责的过程中如果需要技术支持，则在领域层中定义一个表达业务意图的领域服务接口，交由基础设施层采用各种具体技术去实现这一接口。保证领域层（和应用层）不被各种具体技术污染是逻辑分层的第一要务。
• 判断业务层（领域层和应用层）是否被具体技术污染一个方便的方式是检查它们是否有对具体技术框架（例如Spring和Hibernate）的编译时依赖。业务层代码应该只依赖于JDK（java.）、Java规范（javax.），以及一些被广泛使用的类库如commons-lang、Guava、SLF4J、JodaTime等，这些类库本质上可视为对JDK的补充，不是一种具体技术框架。
• 应用层和门面层的区别：应用层属于后端，门面层属于前端。应用层方法的参数和返回值可以包含领域对象，门面层方法的参数通常是字符串和数字等简单值，返回值是简单值或DTO。以转账操作为例子，应用层中的方法签名是这样的：void transferFund(Account from, Account to, Money amount, Date transferTime)，门面层中的方法签名是这样的：void transferFund(String fromAccountNumber, String toAccountNumber, BigDecimal amount, String currency, Date transferTime)。在门面层的实现类中，负责根据账户号码从仓储中获取Account对象，将amount和currency拼装成Money对象，然后以这些对象和transferTime为参数访问应用层中的相应方法。
• 领域层中的领域对象具有领域通用性或行业通用性，意味着可以在基本相同的领域层上建立不同的应用层（就像三极管、二极管、电容、电阻等在电子工业领域具有通用性，可以用来组装收音机、录音机、电视机等不同应用），应用层是应用特定或客户特定的，只为特定的应用或客户定制。相比应用层，领域层对象具备高度的可重用性。例如一套完备的用户管理领域层模块可以被OA、ERP、CRM、HRM、MES等多个应用重用。因为领域对象中封装了业务逻辑，这种重用是非常有价值的。
• 可以基于相同的应用层建立不同的用户接口层，例如Web页面，手机App、BI报表、RESTful Web Service等等。

各层间的调用关系与依赖关系

各层在运行时对象调用关系如下图所示：

各层在编译时的类依赖关系如下图所示：

图中infrastructure是基础设施层，domain是领域层，application是应用层，facade和facade-impl是门面层（前者是门面接口层，后者是门面实现层），webapp是用户接口层（采用web形式）。

这里有几个关键点：

• 基础设施层和其他各层的编译时依赖关系和运行时调用关系是相反的：在运行时，其他各层中的对象调用基础设施层中的对象实例，使用后者提供的服务；而在编译时，基础设施层中的类依赖于其他各层（主要是领域层）中的类。这是通过运用面向对象原则中的依赖倒置原则达到的，在领域层中定义服务接口，而在基础设施层中实现领域层定义的接口。在运行时，通过Spring等IoC容器向领域层中服务接口的客户类注入基础设施层中定义的实现类的实例。依赖倒置原则保证了领域层是主，基础设施层是仆。正如同建筑工程建设中的甲方和乙方，虽然甲方使用乙方提供的产品和服务，但乙方要完成的内容是由甲方指定和控制的，是乙方依赖于甲方，而不是甲方依赖于乙方。
• 代表业务的层（领域层和应用层）不依赖于代表技术的层（基础设施层和用户接口层），代表技术的层依赖于代表业务的层。这是天经地义的——业务提出需求，技术实现业务提出的需求。在保持业务层不变的前提下，可以变更技术层，实现可替换性——例如原来的基础设施层采用MyBatis实现持久化，可以自由替换为用JPA实现持久化；又例如原来的用户接口层基于Swing，可以自由替换为Web界面——在两种情况下，都不需要修改业务层。
• 领域层处于整个系统的核心位置，它在概念上不依赖于其他各层，其他各层都直接或间接依赖于它。领域层是整个系统的核心引擎，直接实现业务目标，攸关业务正确性、可靠性、灵活性和扩展性。应该把最优秀的人才和最大部分的精力放在领域建模和领域层开发上，这才是真正的”领域驱动设计”。
• 领域层应该是整个系统中最”胖”的一层，因为它实现了全部业务逻辑并且通过各种校验手段保证业务正确性，其余各层相对都较”瘦”。如果你的代码中不是如此，你肯定走错了路。胖用户接口层是”以数据库为中心的增删改查”模式的典型症状，胖应用层是事务脚本模式的典型症状。
• 通过定义门面接口（图中的facade），前端和后端概念上互相独立，互不依赖，可以并行开发实现。等到前后端系统都开发完毕，再开发门面实现（图中的facade-impl），将前端和后端系统粘合起来，成为一体。门面层接口的任务是”分”：将前台和后台在概念上分隔开来；门面层实现类的任务是”合”，将前台和后台粘合在一起，成为一个有机统一的完整系统。

设计领域模型的一般步骤

1. 根据需求建立一个初步的领域模型，识别出一些明显的领域概念以及它们的关联，关联可以暂时没有方向但需要有（1：1，1：N，M：N）这些关系；可以用文字精确的没有歧义的描述出每个领域概念的涵义以及包含的主要信息；
2. 分析主要的软件应用程序功能，识别出主要的应用层的类；这样有助于及早发现哪些是应用层的职责，哪些是领域层的职责；
3. 进一步分析领域模型，识别出哪些是实体，哪些是值对象，哪些是领域服务；
4. 分析关联，通过对业务的更深入分析以及各种软件设计原则及性能方面的权衡，明确关联的方向或者去掉一些不需要的关联；
5. 找出聚合边界及聚合根，这是一件很有难度的事情；因为你在分析的过程中往往会碰到很多模棱两可的难以清晰判断的选择问题，所以，需要我们平时一些分析经验的积累才能找出正确的聚合根；
6. 为聚合根配备仓储，一般情况下是为一个聚合分配一个仓储，此时只要设计好仓储的接口即可；
7. 走查场景，确定我们设计的领域模型能够有效地解决业务需求；
8. 考虑如何创建领域实体或值对象，是通过工厂还是直接通过构造函数；

停下来重构模型。寻找模型中觉得有些疑问或者是蹩脚的地方，比如思考一些对象应该通过关联导航得到还是应该从仓储获取？聚合设计的是否正确？考虑模型的性能怎样，等等；

领域建模是一个不断重构，持续完善模型的过程，大家会在讨论中将变化的部分反映到模型中，从而是模型不断细化并朝正确的方向走。领域建模是领域专家、设计人员、开发人员之间沟通交流的过程，是大家工作和思考问题的基础。

本文转至 Koala 开发平台文档：11.1领域驱动设计