域驱动设计：经理和服务

Question

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

Answer 1

尽量使用名称尽可能具体。根据经验，我会avoid the name "Manager"，因为它的意思很模糊。

典型的业务逻辑参与者/名词将是验证者，规则，提供者，主管，导入者/导出者，序列化器，处理器（处理事务）和存储库（您已经拥有的最后一个）。如果单个类执行多个这些函数，则应该将其分解为子类。

你问了一个问题，“这些课程要照顾什么？”事实上，这就是重点。名称SomethingManager告诉您什么。另一方面，OrderValidator非常清楚地告诉你该课程的作用，CustomerHistoryExporter也是如此。服务有点像灰色区域;如果服务是以被动操作命名的，例如ShippingService，则很清楚服务处理的内容，但更好的名称可能类似于ShipmentDispatcher。你希望得到这个想法。

Answer 2

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

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

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

Answer 3

在您决定使用域模型模式的情况下（显然，如果您想要进行DDD），验证，计算和业务规则等业务逻辑肯定构成域模型的一部分（您的业务对象及其关系） ）。

一个很好的一般性参考也可能会给你Martin Fowlers的书'Patterns of Enterprise Application Architecture'。