DDD实体与服务中的方法

Question

我们的团队对DDD来说相当新,并且正在尝试实现当前项目中的一些概念.提出的一个问题是,是将方法放入实体对象还是服务对象.

一些团队成员认为实体应该只保留值,所有功能都应该包含在服务中.其他人认为这使得实体对象贫血,并且他们应该保持与实体相关的功能,而服务对象应该用于更多交叉功能.

我们想知道正式的DDD观点是什么,以及在现实生活中对人们有用的东西.

Answer 1

DDD没有正式的观点,但丰富的Domaim模型的全部目的是避免遗忘域模型,因此明确拒绝在域对象上放置任何行为都违背了它的精神.

有一种观点认为Domain Objects应该是POCO/POJO,这意味着它们不应该包含抽象服务作为成员.但是,这并不意味着他们不能拥有与此类服务交互的方法.

您可以为每个域对象提供的(相关)行为越多越好.

Answer 2

根据快速领域驱动设计，对象分为三种基本类型。

\n\n

\n
• 实体
\n
• 值对象
\n
• 服务
\n

\n\n

应用程序的业务逻辑是在所有这三个对象中实现的，但我们要谨慎地对逻辑进行分区。

\n\n

\n

服务可以对服务于实体和值对象的相关功能进行分组。显式声明服务要好得多，因为它在域中创建了明确的区别：它封装了一个概念。将此类功能合并到实体或值对象中会造成混乱，因为\xe2\x80\x99不清楚这些对象代表什么。

\n

\n\n

另一方面，

\n\n

\n

服务不应取代通常属于域对象的操作。我们不应该为每个需要的操作创建一个服务。但是，当这样的操作作为领域中的重要概念脱颖而出时，就应该为其创建一个服务。服务具有三个特征：

\n\n

\n
1. 服务执行的操作是指自然不属于实体或值对象的域概念。
\n
2. 执行的操作引用域中的其他对象。
\n
3. 该操作是无状态的。
\n

\n

\n\n

因此，有一些明确的标准来确定方法所属的位置。不幸的是，DDD 并不像说业务逻辑属于实体或业务逻辑属于服务那么简单。这两种说法都不正确。答案是两者的结合。

\n\n

最后，不要仅仅为了避免域模型贫乏而向域对象添加方法。

\n\n

\n

当我们创建软件应用程序时，应用程序的很大一部分与领域并不直接相关，而是基础设施的一部分或服务于软件本身。与其他部分相比，应用程序的域部分可能非常小，因为典型的应用程序包含大量与数据库访问、文件或网络访问、用户界面等相关的代码。

\n

\n