贫血领域模型与领域模型

Question

在阅读了关于这种反模式的内容之后再次感到困惑，以及此处对此的许多担忧。

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

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

因为我对这些概念感到很困惑，所以我不确定我所写的内容是否有意义。请随意澄清。

Answer 1

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

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

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

正如之前的回答中所提到的，也许您对数据和持久性的关注会让您分心 true 域建模... < / p>

Answer 2

我想到了两件感兴趣的事情：

• 数据传输对象（DTO）与域对象不同。它们在建筑的不同位置服务于不同的目的 - 不要混淆它们。域对象提供丰富的API ，高内聚。 DTO是应用程序外部接口中使用的被动数据结构 - 非常类似于UI ViewModels，但针对自动化系统而非用户。
• 选择允许您使用持久性无知的ORM后努力。这意味着您可以以无限制的方式定义域模型，只需让ORM将对象映射到关系数据库。

Answer 3

  

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

通过以随意方式添加内容来到达域模型是可能的，但肯定不是域驱动的设计。 （我知道这不是真的有用。我倾向于认为自己非常以数据为中心，在某些情况下，需要付出真正的努力才能从这个角度出发。）