Mat*_*oli 6 domain-driven-design ddd-service
在域驱动设计中,域服务应包含自然不属于实体的操作.
我有习惯为每个实体创建一个服务,并在其中组合一些方法(Organization实体和OrganizationService服务).
但我想的越多:OrganizationService没有任何意义," 组织 " 不是服务,而是一件事.
所以现在我必须添加一个组织深层复制功能,它将复制整个组织聚合,所以我想把它放在一个服务中.
我应该这样做OrganizationService::copyOrganization(o)吗？
或者我应该这样做OrganizationCopyService::copyOrganization(o)？
更一般地说: "服务"是一个包含几个操作的抽象概念,还是一个具体操作的服务？
编辑:更多的例子给出第一个不是那么好:
StrategyService::apply()/cancel()还是StrategyApplicationService::apply()/cancel()？(此处"应用程序"与应用程序层无关;)CarService::wash()还是CarWashingService::wash()？在所有这些示例中,最具体的服务名称似乎是最合适的.毕竟,在现实生活中,"洗车服务"是有道理的.但我最终可能会得到很多服务......
*注意:这不是关于意见的问题!这是关于领域驱动设计方法的精确,可回答的问题.我总是疲惫的接近票数问"我应该"的时候,但有是一个做事的方式DDD*.
我认为域服务只有一种方法是很好的。但是我不认为这是一条规则，就像您在域服务或其他内容上不能使用多个方法。如果接口仅抽象一件事情或一项行为，那么就很容易实现，但是域服务的粒度完全取决于您的受限上下文。有时我们过多地关注低耦合而忽略了高内聚力。