贫血领域模型与领域模型

Question

在读到这个反模式和这里关于它的许多担忧之后，我再次感到困惑。

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

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

因为我对这些概念很困惑，所以我不确定我写的东西是否有意义。请随时要求澄清。

Answer 1

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

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

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

正如早先的回答中提到的，也许你对数据和持久性的关注分散了你对真正的领域建模的注意力……

Answer 2

我的脑海中出现了两个有趣的东西：

• 数据传输对象(DTO)不同于域对象。它们在架构中的不同位置服务于不同的目的--不要混淆它们。域对象提供了一个具有高内聚的富接口。do是在应用程序的外部接口中使用的被动数据结构-非常类似于UI，但它是针对自动化系统而不是用户的。
• 在选择一个允许您使用持久性忽略的对象模型后，会努力工作。这意味着您可以以一种无界的方式定义您的域模型，并简单地将对象映射到关系数据库。

Answer 3

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

通过以随意的方式添加东西来达到领域模型是可能的，但肯定不是领域驱动的设计。(我知道这并不是很有帮助。我自己倾向于认为非常以数据为中心，在某些情况下，要从这种观点中走出来需要付出很大的努力。)