这是一个贫血的领域模型吗？答案

【问题标题】：Is this an anemic domain model?这是一个贫血的领域模型吗？
【发布时间】：2011-08-17 14:29:11
【问题描述】：

我正在尝试构建我的第一个 CRUD 应用程序，但我不明白是否应该使用包含分离的 getter 和 setter 的对象。

如果域对象（如 Zend 快速入门教程中所述）仅包含 getter 和 setter，那是一种反模式吗？从某种意义上说，我们是在不必要地用事务脚本划分域对象？

请指教。

【问题讨论】：

【解决方案1】：

仅当您尝试构建真正的域模型（也称为域驱动设计中的域模型）并最终得到只有状态且没有行为的实体时，贫血域模型才是反模式。

对于简单的 CRUD 应用程序，贫血的领域模型可能是最佳实践，尤其是当您拥有可以让您的工作非常轻松的框架时。

参见 Martin Fowler 关于Anemic Domain Model 和Greg Young's Article 的文章。

【讨论】：

那么，我们对领域模型有两种意义吗？在一次意义上，Zf 快速教程的意义，告诉我们：1）领域模型（通过引用模型类，表示领域对象？） 2）领域驱动设计模式意义上的领域模型？我问这个，因为在提供的链接上，您可以看到声明，getter 和 setter 类首先被视为“域模型”，后来被视为“域对象”......
对象是从模型中创建的
@ArtWorkAD: 嗯......所以，我们不应该说：“域模型是指代表域对象的模型类”，而是应该说：“域模型作为一些模型类（ MVC 的 M 部分上的类），并且这些类负责创建“域对象”。是吗？Arrrhhh ！！请耐心等待我。:))
你有一个感兴趣的领域，你用概念模型来描述它。如果这是一个角色扮演，我们将从模型中创建对象。模型本身给出了关于对象可以做什么或它应该保存和提供什么信息的结构。
@MEM：域模型是您编写的一组类的通用术语，这些类试图将您正在解决的问题的概念模型转换为代码。这个领域模型可以是贫乏的，也可以不是。在进行 DDD 时，您有一组在定义模型时应该遵循的规则/指南——其中一个是没有贫血的实体（没有行为）。最后，我想您可以说“域模型是一组域对象（类），代表以代码建模的问题域”。维基百科是对所有热力学的很好解释。

【解决方案2】：

领域对象与软件的业务逻辑分离。这是procedural programming的一个重要思想。

但是，一些开发人员认为这种模式是反模式的候选者，这意味着它可能是一种无效的做法。

其实你可以考虑缺点

我认为要考虑的最有趣的一点是域模型的对象在任何时候都不能保证它们的正确性。因为它们的突变发生在分离的层中。

我也使用 zend 框架开发了一个 CRUD 应用程序。逻辑和数据之间的清晰分离确实很棒，但是当您进步时，您会意识到层和映射器的数量越来越大。尽量重用你的代码，避免重复。

【讨论】：

您的问题很好地阐明了：“为什么贫血的域模型是一种反模式”。但它没有回答我的问题提出的另一个问题：在表数据网关/数据映射器设计模式上 - 就像 Zend 框架快速指南教程中提出的那样，我们是否也在处理反模式案例？跨度>
没有资源可以将此模式定义为反模式，至少我找不到。我指出，一些开发人员将其视为反模式的候选者。所以一方面你有明确分离的好处，另一方面你有缺点。你看有很多“反对”，这意味着它很可能成为一个反模式
“你的模型表现力较差” - 当你为一个 CRUD 应用程序建模时，除了 get/set 和一些验证之外，模型不需要表达任何东西。 “代码更难重用” - CRUD 通常很简单，并且在这背后有正确的框架不是问题。 “模型的对象不能保证它们的正确性” - 如果您希望从您的域对象中获得这一点，那么您需要开始使用 DDD 设计它们（将它们分组为充当一致性边界的聚合等），并且在这种情况下具有贫血的域模型 IS 和反模式。