贫血领域模型与领域模型

koe*_*oen 19 design-patterns domain-driven-design anti-patterns anemic-domain-model

在阅读了关于这种反模式以及其中关于它的许多问题之后再次感到困惑.

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

我得到的印象是,捕获域模型中必须保留的内容会违反良好实践并创建贫模型域模型反模式.然而,如果你使用关系数据库,就没有办法避免挑出构成对象状态的部分并保存它.

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

Vij*_*tel 17

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

如果您正在使用无所不在的语言,并从您的领域专家那里获得持续的反馈,您就会知道自己处于正确的轨道上(专家应该在看到您的域模型时点头).如果你不做这些事情,你就不会做DDD(埃里克埃文斯谈论它).

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

正如在早期的回答中所提到的,也许你对数据持久性的关注会让你分心于真正的领域建模......


Mar*_*ann 10

我想到了两件感兴趣的事项:

  • 数据传输对象(DTO)与域对象不同.它们在建筑的不同位置服务于不同的目的 - 不要混淆它们.域对象提供了具有高内聚力丰富API.DTO是应用程序外部接口中使用的被动数据结构 - 非常类似于UI ViewModels,但是针对自动化系统而不是用户.
  • 选择一个允许你使用Persistence Ignorance的ORM后努力.这意味着您可以以无限制的方式定义域模型,只需让ORM将对象映射到关系数据库.