在阅读了关于这种反模式以及在SO上的许多相关问题之后，我再次感到困惑。
如果我有一个领域模型并捕获必须持久化的数据到一个数据传输对象中，那么这是否使我的领域模型成为数据的包装器？这种情况下，我将使用贫血领域模型。但是，如果我在该包装器上添加足够的领域逻辑，那么在什么时候它会变成真正的领域模型呢？
我认为在领域模型中捕获必须持久化的内容违反了良好的实践，并创建了贫血领域模型反模式。然而，如果您使用关系型数据库，则无法避免单独提取构成对象状态并保存其状态的部分。
由于我对这些概念感到非常困惑，因此不确定我所写的内容是否有意义。请随时索取澄清。
当一个领域模型包含所有（或大多数）组成业务领域的行为时，它就成为了一个“真实”的领域模型（请注意，我强调的是业务逻辑，而不是UI或其他正交关注点）。
如果你使用通用语言，并从领域专家那里获得持续反馈，你就会知道自己走在正确的轨道上（专家们应该在看到你的领域模型时表示认同）。如果你没有做这些事情，那么你就没有实践DDD（Eric Evans谈论此事）。
至于DTO的问题：不要忽视它们。从实现角度来看，你需要它们在层/级之间传输数据。如何结合DTO和真正的Domain Objects取决于你使用的技术。
正如早先的回答中所提到的，也许你对数据和持久化的关注正在让你分心，远离了真正的领域建模...
我想到两件有趣的事情：
但是如果我在包装器上添加足够的领域逻辑，那么它何时变成真正的领域模型呢？
通过以杂乱的方式添加内容来到达领域模型是可能的，但绝对不是领域驱动设计。（我知道这并没有真正帮助。我自己倾向于非常数据中心化，在某些情况下需要真正努力从这个观点中摆脱出来。）
