贫血模型 - DDD - The Domain Driven Design

贫血模型Anemic Model是一种领域模型，其中领域对象包含很少或没有业务逻辑。这个模型最初由Martin Fowler描述，他认为这种做法是反模式。

这种反模式的根本恐怖之处在于它与面向对象设计的基本思想相悖; 这是将数据和过程结合在一起。

Vaughn Vernon，IDDD，2013年：

贫血领域模型每天都出现在我们行业的各个角落。问题是，大多数开发人员似乎认为这是完全正常的，并且不认识到在他们的系统上使用时会产生严重的副作用。这是一个真正的问题。

因为贫血模型中没有逻辑，因此，负责调用贫血模型的 客户端负责解释领域对象的用途和用途。通常，业务逻辑最终会在名为服务Services等其他类中实现，这些类会转换领域对象的状态。当然，这种方法会导致许多设计问题和缺点。贫血模型导致耦合的大服务

避免贫血领域模型的方法

• 使用private setters.。如果让模型对象的属性直接由外部客户端直接定义，您将失去使用领域事件的机会，您将不得不在实体外的外部方法中验证您的实体。
• 始终验证您的实体的状态，您的实体必须自我验证。
• 避免没有参数的构造函数。当然，您的对象需要一些初始化数据来维持有效状态。
• 领域服务被开发人员用作真正的银子弹，但最终成为贫血模型的最大原因。
• 小心ORM，他们负责自动创建域对象，生成真正的公共setter和公共getter容器，这导致了一个贫血模型。
• 不要使用事务脚本[EAA第110页的P]。
• 使用OOP，当然程序编程比面向对象编程更容易，请记住正确使用OOP是对付贫血模型的一个很好的补救措施。

为什么人们喜欢贫血模型？

我们的许多行业都是由样本代码追随者组成的，但是，通常，示例代码专注于以最简单的方式演示某些概念，而不必担心良好的设计原则。

过度简化的示例代码（通常演示了几个getter和setter）每天都会被复制，而无需考虑项目。