在阅读了这个反模式以及关于它的许多担忧之后再次感到困惑。
如果我有一个域模型并捕获必须保存在数据传输对象中的数据，这是否会使我的域模型成为数据的包装器？在那种情况下，我将使用贫血域模型。但是，如果我在该包装器上添加足够的域逻辑，那么它在什么时候成为真正的域模型呢？
我的印象是，捕获必须在域模型中保留的内容违反了良好实践，并创建了贫乏的域模型反模式。但是，如果您使用关系数据库，则无法避免挑选出构成对象状态的部分并保存它。
因为我对这些概念很困惑，所以我不确定我写的东西是否有意义。随时要求澄清。
2534 次
3 回答
17
当它包含构成业务域的所有（或大部分）行为时，它成为一个“真正的”域模型（注意我强调的是业务逻辑，而不是 UI 或其他正交关注点）。
如果您使用的是通用语言，并且不断从您的领域专家那里获得反馈，您就会知道自己走在正确的轨道上（专家在看到您的领域模型时应该点头）。如果你不做这些事情，你就不是在做 DDD（Eric Evans 谈到它）。
关于 DTO：不要忽视它们。从实现的角度来看，您将需要它们在层/层之间传送数据。如何结合 DTO 和真正的域对象实际上取决于您使用的技术。
正如在较早的答案中提到的那样，也许您对数据和持久性的关注正在分散您对真正领域建模的注意力......
于 2009-11-27T09:13:01.220 回答
10
我想到了两个感兴趣的项目：
- 数据传输对象 (DTO) 与域对象不同。它们在架构中的不同位置服务于不同的目的——不要混淆它们。Domain Objects 提供了具有高内聚性的丰富 API。DTO 是在应用程序的外部接口中使用的被动数据结构- 与 UI ViewModel 非常相似，但针对的是自动化系统而不是用户。
- 在选择允许您使用Persistence Ignorance的 ORM 之后努力。这意味着您可以以无限制的方式定义您的领域模型，并且只需让 ORM 将对象映射到关系数据库。
于 2009-11-27T08:07:50.573 回答
3
但是，如果我在该包装器上添加足够的域逻辑，那么它在什么时候成为真正的域模型呢？
通过以随意的方式添加东西来达到领域模型是可能的，但肯定不是领域驱动的设计。（我知道这并没有真正的帮助。我倾向于认为自己非常以数据为中心，在某些情况下，需要付出真正的努力才能将自己从这个观点中拉出来。）
于 2009-11-27T03:25:29.037 回答