点击上方蓝色“
石杉的架构笔记”，选择“设为星标”
回复“PDF”获取独家整理的学习资料！
要想深入掌握和了解 DDD 领域驱动设计的核心，那无论如何也绕不开两大较为抽象的概念——“贫血模型”、“
充血模型
”：
-
贫血模型即事务脚本模式。
-
充血模型即领域模型模式。
贫血模型最
早广泛应用源于EJB2，最强盛时期则是由Spring创造，将：
-
“行为”（逻辑、过程）；
-
“状态”（数据，对应到语言就是对象成员变量）。
分离到不同的对象中：
——曾经Spring的作者Rod Johnson也承认，Spring不过是在沿袭EJB2时代的“事务脚本”，也就是面向过程编程。
贫血领域模型是一个存在已久的反模式，目前仍有许多拥趸者。
Martin Fowler 曾经和 Eric Evans 聊天谈到它时，都觉得这个模型似乎越来越流行了。作为领域模型的推广者，他们觉得这不是一件好事。
贫血领域模型的基本特征是：它第一眼看起来还真像这么回事儿。项目中有许多对象，它们的命名都是根据领域来的。对象之间有着丰富的连接方式，和真正的领域模型非常相似。但当你检视这些对象的行为时，会发现它们基本上没有任何行为，仅仅是一堆getter/setter。
其实，这些对象在设计之初就被定义为只能包含数据，不能加入领域逻辑；逻辑要全部写入一组叫Service的对象中；而Service则构建在领域模型之上，需要使用这些模型来传递数据。
这种反模式的恐怖之处在于：它完全和面向对象设计背道而驰。
面向对象设计主张将数据和行为绑定在一起，而贫血领域模型则更像是一种面向过程设计，Martin Fowler和Eric在Smalltalk时就极力反对这种做法。更糟糕的是，很多人认为这些贫血领域对象是真正的对象，从而彻底误解了面向对象设计的涵义。
如今，面向对象的概念已经传播得很广泛了，而要反对这种贫血领域模型的做法，还需要更多论据。贫血领域模型的根本问题是，它引入了领域模型设计的所有成本，却没有带来任何好处。最主要的成本是将对象映射到数据库中，从而产生了一个O/R（对象关系）映射层。
只有当你充分使用了面向对象设计来组织复杂的业务逻辑后，这一成本才能够被抵消。如果将所有行为都写入到Service对象，那最终你会得到一组事务处理脚本，从而错过了领域模型带来的好处。正如martin在企业应用架构模式一书中说到的，领域模型并不一定是最好的工具。
将行为放入领域模型，这点和分层设计（领域层、持久化层、展现层等）并不冲突。因为领域模型中放入的是和领域相关的逻辑——验证、计算、业务规则等。如果你要讨论能否将数据源或展现逻辑放入到领域模型中，这就不在本文论述范围之内了。
一些面向对象专家的观点有时会让人产生疑惑，他们认为的确应该有一个面向过程的服务层。但是，这并不意味着领域模型就不应该包含行为。事实上，service层需要和一组富含行为的领域模型结合使用。
Eric Evans的Domain Driven Design一书中提到：
应用层（即Service层）
描述应用程序所要做的工作，并调度丰富的领域模型来完成它。这个层次的任务是描述业务逻辑，或和其它项目的应用层做交互。这层很薄，不包含任何业务规则或知识，仅用于调度和派发任务给下一层的领域模型。这层没有业务状态，但可以为用户或程序提供任务状态。
领域层（或者叫模型层）
表示业务逻辑、业务场景和规则。该层次会控制和使用业务状态，即使这些状态最终会交由持久化层来存储。总之，该层是软件核心。
服务层很薄——所有重要的业务逻辑都写在领域层。他在服务模式中复述了这一观点：如今人们常犯的错误是不愿花时间将业务逻辑放到合适的领域模型中，从而逐渐形成面向过程的程序设计。
我不清楚为什么这种反模式会那么常见。我怀疑是因为大多数人并没有使用过一个设计良好的领域模型，特别是那些以数据为中心的开发人员。此外，有些技术也会推动这种反模式，比如J2EE的Entity Bean，这会让我更倾向于使用POJO领域模型。
总之，如果你将大部分行为都放置在服务层，那么你就会失去领域模型带来的好处。如果你将所有行为都放在服务层，那你就无可救药了。
优点
简单：
缺点
无法良好的应对复杂逻辑：
