域驱动设计:经理和服务

Question

我在应用程序中创建了一些业务逻辑,但我不确定如何或在何处封装它,我使用了存储库模式进行数据访问,我看到一些使用DDD的项目,其中包含一些带有"服务"后缀和"经理"后缀,这些条款中的每一个都假设在DDD中处理？

Answer 1

尽量使用名称尽可能具体.根据经验,我会避免使用"经理"这个名称,因为它的含义非常模糊.

典型的业务逻辑参与者/名词将是验证者,规则,提供者,监督者,进口商/出口商,序列化者,处理者(处理交易)和存储库(您已经拥有的最后一个).如果单个类执行多个这些函数,则应该将其分解为子类.

你问了一个问题,"这些课程会照顾什么？" 事实上,这就是重点.这个名字SomethingManager什么也没告诉你. OrderValidator另一方面,它非常清楚地告诉你这个课程的作用CustomerHistoryExporter.服务有点像灰色区域; 如果服务是以被动操作命名的ShippingService,那么很清楚服务处理的是什么,但更好的名称可能是这样的ShipmentDispatcher.我希望你能得到这个想法.

Answer 2

不要过于拘泥于命名法; 通常,服务为类提供一些东西以减少耦合,而管理器仍然更加通用 - 可能是跟踪其他对象和/或状态的类.

DDD方法更重要的是实际建模域.这在很大程度上取决于您的行业(或您的应用所针对的行业)以及您正在构建的应用程序类型."在哪里封装？" 是这个过程的基本驱动力,但它主要归结为创建现实世界实体的阶级表示:员工,客户,供应商,发票,交易,报价,合同等.

服务和管理人员可以帮助在运行时将这些事物粘合在一起,这种命名法有助于将这些类与封装域逻辑的事物区分开来.