19

在阅读了这个反模式以及关于它的许多担忧之后再次感到困惑。

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

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

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

4

3 回答 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 回答