DDD 领域服务：一个服务类应该包含什么？

Question

在领域驱动设计中，领域服务应该包含自然不属于实体内部的操作。

我的习惯是为每个实体创建一个服务并在其中分组一些方法（Organization 实体和OrganizationService 服务）。

但我越想：OrganizationService 没有任何意义，“组织”不是服务，而是事物。

所以现在我必须添加一个将复制整个组织聚合的组织深层复制功能，所以我想将它放在一个服务中。

我应该这样做：OrganizationService::copyOrganization(o)？

或者我应该这样做：OrganizationCopyService::copyOrganization(o)？

更一般地说：“服务”是一个包含多个操作的抽象概念，还是一个服务是一个具体的操作？

编辑：第一个例子不是很好：

• StrategyService::apply()/cancel() 还是 StrategyApplicationService::apply()/cancel()？ （这里的“应用”与应用层无关；）
• CarService::wash() 或 CarWashingService::wash()?

在所有这些示例中，最具体的服务名称似乎是最合适的。毕竟，在现实生活中，“洗车服务”是有道理的。但我最终可能会得到很多服务......

*注意：这不是关于意见的问题！这是一个关于领域驱动设计方法的精确、可回答的问题。当我问“我应该”时，我总是厌倦了接近投票，但有 一种 DDD 的做事方式。*

Answer 1

这有点基于意见，我想将其添加为评论，但空间不足。

我相信在这种情况下，将这些方法组合成一个具有不同构造方法的单独的组织工厂服务是有意义的。

   interface OrganizationFactory{
       Organization createOrganization();
       Organization createOrganizationCopy(Organization organization);
   }

我想这将符合 信息专家 模式和 DRY 原则 - 一个类具有有关特定对象创建的所有信息，我看不出任何原因在不同的地方重复这个逻辑。

不过，有趣的是，在 ddd 中定义了工厂模式

转移创建复杂对象实例的责任和 聚合到一个单独的对象，它本身可能没有 域模型中的责任，但仍然是域的一部分 设计。提供封装所有复杂程序集的接口 并且不需要客户端引用具体的类 被实例化的对象。

“对象”这个词在一般意义上甚至不必是单独的类，也可以是工厂方法（我的意思是类的方法和模式factory method) - 后来 Evans 给出了 Brokerage Account 的工厂方法的示例，它创建了 Trade Order 的实例。

这本书提到了GoF工厂模式家族，我不认为有一种特殊的DDD工厂分解方式——重点是创建的对象不是半生不熟的，工厂方法应该添加尽可能少尽可能多的依赖。

更新 DDD 没有附加到任何特定的编程范式，而问题是关于面向对象 分解，所以我不认为 DDD 可以提供任何关于每个对象的方法数量的特别建议。

有些人使用strange rules of thumb，但我相信你可以直接使用High Cohesion principle，并将具有高度相关职责的方法放在一起。因为这是一个 DDD 问题，所以我想它是关于域服务（即不是基础设施服务）。我认为服务应该根据它们在域中的职责进行划分。

更新 2 无论如何 CarService 可以做到 CarService::wash()/ CarService::repaint() / CarService::diagnoseAirConditioningProblems() 但很奇怪 CarWashingService 会做到 CarWashingService::diagnoseAirConditioningProblems() 这就像乔姆斯基的生成语法 -该语言中的某些陈述（句子）有意义，有些则没有。但是如果你的句子包含太多主语（超过 5-7 个），即使是有效的语言句子，也会很难理解。

Answer 2

我认为如果域服务只有一种方法会很好。但我不认为这是一个规则，比如你在域服务或其他东西上不能有多个方法。如果接口只抽象一件事或一种行为，它当然很容易维护，但域服务的粒度完全取决于您的有界上下文。有时我们过于关注低耦合而忽略了高内聚。