DDD领域驱动知识概览

本文未完成，持续完善中

DDD是什么

DDD：Domain Drive Design。领域驱动设计。

软件系统是用计算机语言来表达业务逻辑，需要先对业务进行建模分析。没有DDD我们也是要建模分析的，而DDD是对业务逻辑进行分析的方法论，总结了一套如何分析一个系统的业务逻辑的方法论，可以使用这套方法来对复杂业务系统进行高效的建模分析。

统一语言

统一语言是沟通的前提，英语和汉语是无法直接对话的。DDD一开始就提出了统一语言的重要性，我们需要制定业务术语，大家使用一种术语来沟通。统一语言要贯穿整个软件工程过程(文档，代码…) 以及参与的人(产品，架构，研发，测试…)。

限界上下文

有了统一语言，接下来我们可以对系统进行分析了。我们无法对一个庞大的业务进行分析，首先需要对系统进行拆分，对较大的逻辑分而治之，在不同的层次分别分析，这里就要用到界限上下文的概念。

限界上下文不仅仅是把大得逻辑拆分为小的逻辑，还有一个抽象的作用，就是隔离业务域。现实世界的实体都是参与很多场景，(比如作为我们一个普通人来说，在公司你是一名雇员，在家庭中你可能是老公(或老婆)，如果去收费公园门卫只关心你有无门票。)，世界是联系在一起的。但我们设计计算机系统是为了解决一部分场景，并不是仿真整个世界。所以我们如果设计公司的员工管理系统，以及公园的售票系统，对于通用的一个人，关心的点事不同的。这就是抽象，对事物抽出来某一个方面，隐藏掉无关方面，这就是DDD的【限界上下文】的概念。

上下文映射图

通过界限上下文，我们可以设计出来不同的子域，但不可避免，不同子域可能需要打交道的(当然也可能完全隔离)，当需要打交道的时候，比如公司的OA系统和薪水管理系统是可能打交道的。当不同系统需要打交道的时候，就需要使用到防腐层(ACL)，通过防腐层的转换翻译，只把对方系统需要的信息传递过去，尽量减少不同子域的依赖，每个子域内只关心自己的域内知识就可以。

注：不同的子域可以使用微服务实现，微服务的理念和子域的划分在目的上是一致的，都是为了隔离和内聚。

聚合根，实体，值对象

当你分析清楚了你要处理的领域，就需要协调领域内的多个对象来完成域内功能，从面相对象的角度来说，功能完成是通过对象属性和行为来完成的(过程化表述是通过数据结构+算法来完成的)。如下图我们的程序处理过程可能需要协作多个对象来完成。

如果一件事情要协调多个人来做，我们一般都会找个代理人，什么事情都找他就行(想象下一棵树的所有树叶散落在一起和通过枝干有序的整理在一起对比图)，这个代理就是聚合根的概念：

你不用一个个的找实体去做事，问聚合根就知道了，聚合根下有实体和值对象，他们的区别需要看场景，如果你只关心我想要用一支笔，能写字就行，那就是值对象；如果你就要你的那支喜欢的笔，哪怕同一型号的都不行，那就是实体；也就是值对象可替换，只关心功用，实体在乎的是生命周期，就算那支笔坏了，还是你那支喜欢的笔。

DDD聚合要保持一致性

设计一个聚合，一定要保持聚合时刻处于一致性状态；从聚合出生(从repository中取出或创建)开始，聚合的属性在客户看来都是完整的，客户可以随时安全的调用聚合内的全部公开方法，调用前后聚合依然保持一致性，可以继续提供安全的服务；如果有些方法在聚合内不能保持安全调用，比如要求客户先进行某些操作(例如解密)，然后才能进行某些操作，那么可以考虑把方法在领域服务中实现。

为什么聚合要求先调用某些前置服务就是不一致的？因为这就说明，如果客户不先调用某个前置操作，直接调用该服务就会出现不可期的结果或异常，那么调用前置操作之前，聚合的该服务处于不可用状态，也就是不一致的状态。

总结：聚合提供了一致性的边界。