这本书读起来不像有些大白文一样那么顺口，而且有不少专业生僻词汇，但每个小节，几乎都有对应的应用举例来说明，确实能帮助毕业生、工程师或是架构师等得到足够的信息来应用于实际项目中。当然，读书过程中也会经常有这样的疑问，为什么要将简单的业务设计拆分成更细小的功能模块？但回想过来，有时候就是这些简单的业务，当后期有需求变更或者调整的时候，由于一开始没有很好的进行领域分析，使得整个项目变更花费巨大。

DDD设计模式很好，它对于当前面向对象的设计有着无与伦比的契合度，但每个项目都是“独一无二”的，所以也要避免生搬硬套，造成不必要的开销和争论。本书的作者Eric Evans“领域驱动之父”，但他后面也指导过很多开发团队开展极限编程的实践。所以没有固定的模式，但需要很好的方法和工具来指导项目满足基准来执行。

什么是DDD？- 个人认为领域驱动设计（DOMAIN-DRIVEN DESIGN）是一种设计方法，是一种应对业务或者用户case复杂性的一种拆解、思考和交流的方式。它对于一些复杂的领域进行理解、拆分，最终细化，从而得到项目相关方都能很明确的清楚业务需求、规则以及实施方案。

如何在项目中应用？- 在Eric Evans的《领域驱动设计》一文中提出了很多实用的建模工具：聚合、实体、值对象、工程、仓储、领域服务、领域事件等，我们可以合理的选择工具，来设计每一个子域的领域模型。

举例说明：假如有一家企业需要公司开发一套“孵化器运营管理系统”，则如何利用DDD来帮助并最终成功实施项目呢？

1. 抽象实体概念

2. 建立相互之间的关系

当然，如果事先设计好了数据库，则数据表结构和关系也就相当于领域模型图。目前大家都用的EF等ORM框架其实也是参考DDD的设计模式。

3. 业务逻辑实现

项目经理和开发人员根据1和2中的实体以及关系模型来进行业务逻辑的实现。

综上所示，DDD的核心作用主要有：

1. 抽象了业务的核心概念，并建立了相互的关系

2. 领域模型对领域内的状态进行积极主动的维护

3. 领域模型对实体的业务规则，数据一致性进行积极主动的维护

在书中，也提到了DDD模型在软件开发中所需表述的模型，共分为：关联和模式。

1. 关联：抽象各个实体的关系，在实际需求中会有大量“多对多”的关联，一般在头脑风暴进行领域探索时，会针对所有的关联进行分析和罗列，但一定要做好一点就是：要使得关联易于控制，需要做到三个方面。(1)规定一个遍历方向 (2)添加一个限定符，尽量减少多重和多向关联 (3)消除不必要的关联

2. 模式一：四层架构（最常用的，也是书中Eric提到的）

模式二：五层架构（对四层架构的补充）

Context在架构中起到上下文作用，将Domain层的领域对象cast成对应的Role，让Role交互成来完成业务逻辑。

模式三：六边形架构

这种架构中，不同客户通过“平等”的方式与系统进行交互，如果有新的客户需要，则需要添加一个新的适配器将客户的输入转化成能被系统API所识别的参数，同时，对于每种特定的输出，都存在一个新建的适配器来负责完成相应的数据转化。所以六边形架构中会用到大量的抽象技术，高层模块不应该依赖于底层木块，两者都应该依赖于抽象；抽象不应该依赖于业务细节，细节应该依赖于抽象去实现。当然书中 也提到，六边形也衍生出了三种变体：分别为洋葱架构、干净架构和Life Preserver设计等。

优势在哪里?

1. 业务通过业务专家的整理变得易于读懂，而且对于各个业务关系也都有了明确的认识

2. 开发人员只需要关注整个结构中的某一层即可

3. 很容易用新的实现技术来替换原有层次的实现

4. 很好的降低耦合性

5. 有利于软件开发的标准化

6. 有利于逻辑间的复用性

难点是什么? 因为业务需求多种多样，所以一个公司很难有专家对各个方面都很精通，并且要会做业务分析，模块划分，画好领域模型图，并设计好各个模型和功能，其实是非常空难的。另外当业务发生变化时，也需要业务专家先修改领域模型，开发人员再根据模型进行调整，也无形中牺牲了开发效率。

后记 - 有难点，可以在实际操作中去规避，毕竟我们所涉及到的项目复杂程度也一般，所以能够找到合适方法或者模式，能够在以后的项目实施中起到很好的引导和指引的作用，起到事倍功半的效率，才能对于个人、对于客户、对于公司之间建立起足够的信任、尊重关系，为以后的发展定下基调。

对于DDD模式，个人觉得是一个项目实施的指导基准，具体怎么去运用，还需要各位相关方来确定符合自己项目的工具或者技术，而不能一味的强加到项目上，毕竟DDD只是一种模式、理念。