DDD专栏3：DDD是如何指导应用架构的？

03、DDD是如何指导应用架构的？

​ 在上一章节中，我们将一个典型的事务脚本式的支付功能代码推演成了DDD的四层架构，其中引入了很多DDD中的概念。像领域服务、实体、值对象、防腐层、贫血模型、充血模型等。但是过程毕竟比较匆忙，还无法理解DDD如何在方法层面指导应用架构设计。这一节，我们就来仔细讨论下在DDD落地过程中，应该怎么样来设计这些基础的概念。

贫血模型 vs 充血模型

​ DDD与传统MVC最为明显也是最为具体的区别就是底层的这两种设计思想，贫血模型 和 充血模型。

​ 贫血模型基于一些非常简单POJO对象来构建整个应用，这些POJO对象在java中就是一些只有属性和getter、setter的类，只是一种携带数据的结构，并不包含任何的业务逻辑。我们会将所有的业务逻辑集中到上层的事务脚本中来处理。这是MVC最为常见的设计方式。

​ 充血模型中的实体则包含了实体的属性和所有内敛的业务操作。这些业务操作不再需要在事务脚本中实现，而是在实体内部直接实现。在充血模型中也会有service来辅助构建业务流程，但是service的作用被极大的简化，只是去调用实体对象中的相应方法，而并不管具体实现。这是DDD推荐的设计方式。

​ 正是这两种最底层基础思想的差异，才造成了DDD与传统MVC整体上迥异的架构风格。如何来评价这两种设计模型呢？绝对的说谁好谁坏是没有意义的，我们还需要尽量深入的比较这两种设计模型。

​ 在2004年，Eric Evans提出《领域驱动设计》这本巨著时，其实并没有贫血模型与充血模型概念，大家也都是习惯性的一直使用着贫血模型。直到另一位软件大师Martin Fowler在他自己的博客中才提出了"贫血模