贫血领域模型

原文：http://www.martinfowler.com/bliki/AnemicDomainModel.html

贫血领域模型是一个存在已久的反模式，目前仍有许多拥趸者。一次我和Eric Evans聊天谈到它时，都觉得这个模型似乎越来越流行了。作为领域模型的推广者，我们觉得这不是一件好事。

贫血领域模型的最初症状是：它第一眼看起来还真像这么回事儿。项目中有许多对象，它们的命名都是根据领域来的。对象之间有着丰富的连接方式，和真正的领域模型非常相似。但当你检视这些对象的行为时，会发现它们基本上没有任何行为，仅仅是一堆getter和setter的集合。其实这些对象在设计之初就被定义为只能包含数据，不能加入领域逻辑。这些逻辑要全部写入一组叫Service的对象中。这些Service构建在领域模型之上，使用这些模型来传递数据。

这种反模式的恐怖之处在于，它完全是和面向对象设计背道而驰。面向对象设计主张将数据和行为绑定在一起，而贫血领域模型则更像是一种面向过程设计，我和Eric在Smalltalk时就极力反对这种做法。更糟糕的时，很多人认为这些贫血领域对象是真正的对象，从而彻底误解了面向对象设计的涵义。

如今，面向对象的概念已经传播得很广泛了，而要反对这种贫血领域模型的做法，我还需要更多论据。贫血领域模型的根本问题在于，它引入了领域模型设计的所有成本，却没有带来任何好处。最主要的成本是将对象映射到数据库中，从而产生了一个对象关系映射层。只有当你充分使用了面向对象设计来组织复杂的业务逻辑后，这一成本才能够被抵消。如果将所有行为都写入到Service对象，那最终你会得到一组事务处理脚本，从而错过了领域模型带来的好处。正如我在企业应用架构模式一书中说到的，领域模型并不一定是最好的工具。

还需要强调的是，将行为放入领域模型，这点和分层设计（领域层、持久化层、展现层等）并不冲突。因为领域模型中放入的是和领域相关的逻辑——验证、计算、商业规则等。如果你要讨论能否将数据访问和展现逻辑放入到领域模型中，这就不在本文论述范围之内了。

一些面向对象专家的观点有时会让人产生疑惑，他们认为的确应该有一个面向过程的服务层。但是，这并不意味着领域模型就不应该包含行为。事实上，服务层需要和一组富含行为的领域模型结合起来使用。

Eric Evans的领域驱动设计一书中有关于分层的论述：

应用层（也就是上文中的服务层）：用来描述应用程序所要做的工作，并调度丰富的领域模型来完成它。这个层次的任务是描述业务逻辑，或和其它项目的应用层做交互。这个层次很薄，它不包含任何业务规则或知识，仅用于调度和派发任务给下一层的领域模型。这个层次没有业务状态，但可以为用户或程序提供任务状态。

领域层（或者叫模型层）：用于表示业务逻辑、业务场景和规则。这个层次会控制和使用业务状态，即使这些状态最终会交由持久化层来存储。总之，这个层次是软件的核心。

关键点在于服务层是很薄的——所有重要的业务逻辑都写在领域层。他在服务模式中复述了这一观点：

如今人们常犯的错误是不愿花时间将业务逻辑放置到合适的领域模型中，从而逐渐形成面向过程的程序设计。

我不清楚为什么这种反模式会那么常见。我怀疑是因为大多数人并没有使用过一个设计良好的领域模型，特别是那些以数据为中心的开发人员。此外，有些技术也会推动这种反模式，比如J2EE的Entity Bean，这会让我更倾向于使用POJO领域模型。

总之，如果你将大部分行为都放置在服务层，那么你就会失去领域模型带来的好处。如果你将所有行为都放在服务层，那就无可救药了。