领域驱动设计中的领域模型与领域模型

Question

我最近读了一篇关于"贫血域模型模式“的文章，引起了我的注意。当我阅读这篇文章时，我发现贫血的领域模型描述适用于我所从事和构建的许多项目。我从来没有认为这是一个糟糕的设计决策，因为它感觉非常自然。我认为，在域模型重量轻且不太复杂的情况下，贫血领域模型的名称非常适合。为什么在领域模型中增加复杂性，而不需要仅仅是因为“贫血域模型”的标题不能恰当地描述您的代码？

问题：在什么时候将更多的代码复杂性填充到服务/应用程序层变得正确，而倾向于将实体对象的复杂性暴露出来？我完全赞成在一个实体上有一个“总计”属性，在这个属性中，它可以在内部计算出“总计”的值。我不想让实体直接与其他各种类型通信，以确定其中一个属性的结果。那么，贫血域模型的概念是反模式的，还是关注点的良好分离？标题贫血领域模型总是一件坏事吗？

只是好奇别人对这个设计(反)模式有什么想法。

Answer 1

如果域是轻量级的(阅读:不复杂)，建议的方法是在核心域层中使用一个简单的ActiveRecord类型对象。通常DB表和域对象之间是一对一的映射，这里没有很多“逻辑”。您的应用程序只是在数据库和UI之间移动记录，并允许简单的CRUD操作。

对于复杂的域，您将构建一个核心域模型，其中一些对象最终映射到DB表，而有些对象可能不映射并表示域中的其他概念(除了普通数据之外)。如果应用程序需要多个域对象之间的协调，则应用程序的逻辑应该在适当时在对象中，或者在服务对象中。

贫血域模型反模式适用于当您有一个复杂的域，但是您没有适当地将一些逻辑放在域对象中，而将一些逻辑放在服务中，而是将所有(或几乎所有)逻辑放在核心域对象的外部。

这里的关键区别在于你把逻辑放在哪里。如果您没有太多，显然域对象看起来只是简单的数据容器。如果您有复杂的逻辑，不要仅仅将其全部从域对象中提取出来，而是将其适当地分离到核心域对象和域服务之间。

Answer 2

G‘’day！

如果将逻辑置于域对象之外，则会完全失去一个主要的OO概念:封装(或数据隐藏)。

AOP在一定程度上弥补了它的不足，但毕竟，面向对象的关键问题之一已经消失。

你好，斯特凡