在阅读了关于这种反模式以及这里关于它的许多担忧之后再次感到困惑。贫血领域模型与领域模型
如果我有一个域模型并捕获必须在数据传输对象中保存的数据，那么这是否会使我的域模型成为数据的包装？在那种情况下，我会使用贫血域模型。但是，如果我在该包装上添加足够的域逻辑，那么它在什么时候成为真正的域模型呢？
我得到的印象是，捕获域模型中必须坚持的内容违反了良好实践并创建了贫血域模型反模式。但是，如果您使用关系数据库，则无法避免单独找出导致对象状态并保存的部分。
由于我对这些概念很困惑，我不确定我写的是否合理。随意澄清。
它成为一个“真正的”域模型时，它包含了所有（或大部分）行为，构成了商业领域的（请注意，我强调业务逻辑，而不是UI或其他正交关注）。
如果您正在使用通用语言，并从领域专家越来越不断的反馈，你就会知道，你在正确的轨道上，当他们看到你的域模型（专家应点头）。如果你没有做这些事情，你不会做DDD（Eric Evans speak about it）。
在DTO的基础上：不要忽视它们。从实现的角度来看，您需要它们在不同层/层之间传输数据。您如何将DTO和真正的域对象结合在一起，实际上取决于您使用的技术。
，如前面的回答提到了，也许你的焦点数据和持久从真正域建模会让你分心...
但是，如果我在该包装上添加了足够的领域逻辑，那么它在什么时候成为真正的领域模型呢？
通过以偶然的方式添加东西来达到域模型是可能的，但是肯定不是域驱动的设计。 （我知道这并不是真的有用，我倾向于认为自己非常以数据为中心，并且在某些情况下需要真正努力从这个角度拉下自己的力量。）
感兴趣的两个项目出现在我的脑海中：