DDD实体与服务中的方法

Question

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

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

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

Answer 1

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

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

您可以为每个域对象提供的（相关）行为越多越好。

Answer 2

我们通常非常擅长为所有事情提供示例，但是当涉及到 DDD 架构时，每个工程师似乎都是一个理论物理学家，并且在没有任何代码作为示例的情况下撰写有关该主题的文章。

Answer 3

根据Domain Driven Design Quickly，存在三种基本类型的对象。

• 实体
• 值对象
• 服务

在这三个对象中都实现了应用程序的业务逻辑，但是请谨慎选择逻辑。

  

服务可以将服务实体和值对象的相关功能分组。显式声明Service更好，因为它在域中创建了明显的区别：它封装了一个概念。将这种功能合并到实体或值对象中会造成混乱，因为尚不清楚这些对象代表什么。

另一方面，

  

服务不应替换通常属于域对象的操作。我们不应该为所有需要的操作创建服务。但是，当此类操作在域中成为重要概念时，应为其创建服务。服务具有三个特征：

     

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

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

最后，不要只是为了避免贫血的领域模型而向领域对象添加方法。

  

当我们创建软件应用程序时，该应用程序的很大一部分与域没有直接关系，但是它是基础结构的一部分或为软件本身提供服务。与其他应用程序相比，应用程序的域部分可能很小，这是可以的，因为典型的应用程序包含许多与数据库访问，文件或网络访问，用户界面等有关的代码。