贫血领域模型与领域模型答案

【问题标题】：anemic domain model versus domain model贫血领域模型与领域模型
【发布时间】：2010-12-20 19:26:17
【问题描述】：

在阅读了这个反模式以及关于它的许多担忧之后再次感到困惑。

如果我有一个域模型并捕获必须保存在数据传输对象中的数据，这是否会使我的域模型成为数据的包装器？在那种情况下，我将使用贫血域模型。但是，如果我在该包装器上添加足够多的域逻辑，那么它在什么时候成为真正的域模型呢？

我的印象是，捕获必须在域模型中保留的内容违反了良好实践，并创建了贫乏的域模型反模式。但是，如果您使用关系数据库，则无法避免挑出构成对象状态的部分并保存它。

由于我对这些概念很困惑，我不确定我写的内容是否有意义。随时要求澄清。

【问题讨论】：

【解决方案1】：

当它包含构成业务领域的所有（或大部分）行为时，它就变成了一个“真正的”领域模型（注意我强调的是 业务逻辑，而不是 UI 或其他正交问题）。

如果您使用的是通用语言，并从您的领域专家那里获得持续的反馈，您就会知道自己是在正确的轨道上（专家在看到您的域模型时应该点头）。如果你不做这些事情，你就不是在做 DDD (Eric Evans speak about it)。

关于 DTO：不要忽视它们。从实现的角度来看，您将需要它们在层/层之间传送数据。如何结合 DTO 和真正的域对象实际上取决于您使用的技术。

正如之前的回答中提到的，也许您对 data 和 persistence 的关注正在分散您对 true 领域建模的注意力...

【讨论】：

【解决方案2】：

我想到了两个感兴趣的项目：

数据传输对象 (DTO) 与域对象不同。它们在架构中的不同位置服务于不同的目的——不要混淆它们。域对象提供了一个丰富的 API，具有高内聚性。 DTO 是在应用程序的外部界面中使用的被动数据结构 - 与 UI ViewModel 非常相似，但针对的是自动化系统而不是用户。
在选择允许您使用Persistence Ignorance 的 ORM 后努力。这意味着您可以无限制地定义领域模型，只需让 ORM 将对象映射到关系数据库即可。

【讨论】：

【解决方案3】：

但是，如果我在该包装器上添加足够多的域逻辑，那么它在什么时候成为真正的域模型？

通过随意添加东西的方式达到域模型是可能的，但肯定不是域驱动设计。（我知道这并没有真正的帮助。我自己倾向于以数据为中心，在某些情况下，需要付出真正的努力才能将自己从这个观点中拉出来。）

【讨论】：