试图在软件中解决复杂业务问题非常困难，但使用Domain Model模式时，首先为真实的业务模型创建一个抽象的模型。有了这个模型之后，就可以对复杂逻辑进行建模：追踪真实的领域并在领域模型中重建工作流和处理流程。与Transaction Script模式和Active Record模式相比，Domain Model模式的另一个优势是，由于它不包含数据访问代码，因此可以很容易地进行单元测试而不必模拟并隔离数据访问层所依赖的类。另外，Domain Model模式可能并不总能匹配应用程序需求。它的强大之处在于处理复杂的业务逻辑，但对于只包含非常少量业务逻辑的应用程序而言，采用一个全方位的领域模型有大材小用之嫌。该模式的另一个不足之处在于，与Active Record和Transaction Script模式相比，为了精通领域模型模式，需要面临陡峭的学习曲线。需要很多时间和经验才能高效地使用该模式，而且最重要的是，需要对正在试图建模的业务领域有全面的了解。

4.1.4  Anemic Domain Model

Anemic Domain Model有时候被称为一种反模式。初看起来，该模式与Domain Model模式非常类似，仍会找到表示业务领域的领域对象。但这些领域对象中不包含任何行为。相反，这些行为位于模型之外，而让领域对象作为简单的数据传输类。

这种模式的主要不足之处在于，领域服务扮演更加过程式的代码，与本章开头看过的Transaction Script模式比较类似，这会带来一些与之相关的问题。其中一个问题就是违背了“讲述而不要询问”原则，也就是对象应该告诉客户它们能够做什么或不能够做什么，而不是暴露属性并让客户端来决定某个对象是否处于执行给定动作所需的状态。

如果考虑用于领域模型练习的示例，那么领域对象Transaction和BankAccount的逻辑现在被剥离出来，它们只是数据容器，代码如下：