贫血模型 - 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)每天都会被复制,而无需考虑项目。