domain-driven-design - DDD域服务: what should a service class contain?

Question

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

我的习惯是为每个实体创建一项服务 并将其中的一些方法分组(Organization 实体和 OrganizationService 服务)。

但我越想:OrganizationService没有任何意义，“组织”是不是 服务，就是一件事。

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

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

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

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

编辑 :鉴于第一个例子不是很好，更多的例子:

StrategyService::apply()/cancel()或 StrategyApplicationService::apply()/cancel() ? (这里的“应用”与应用层无关；)

CarService::wash()或 CarWashingService::wash() ?

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

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

Answer 1

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