领域驱动设计：经理和服务答案

【问题标题】：Domain driven design: Manager and service领域驱动设计：经理和服务
【发布时间】：2010-03-12 23:14:51
【问题描述】：

我正在应用程序中创建一些业务逻辑，但我不确定如何或在哪里封装它，我使用存储库模式进行数据访问，我看到一些使用 DDD 的项目有一些类带有“Service”后缀和“manager”后缀的每个类在 DDD 中应该注意什么？

【问题讨论】：

标签： c# .net design-patterns domain-driven-design

【解决方案1】：

名称尽量具体。根据经验，我会avoid the name "Manager"，因为它的含义很模糊。

典型的业务逻辑参与者/名词是 Validators、Rules、Providers、Supervisors、Importers/Exporters、Serializers、Processors（处理交易）和 Repositories（您已经拥有的最后一个）。如果单个类执行多个这些功能，则可能应该将其分解为子类。

您问了一个问题，“这些课程负责什么？”事实上，这就是重点。 SomethingManager 这个名字什么也没告诉你。另一方面，OrderValidator 和CustomerHistoryExporter 一样，非常清楚地告诉你这个类是做什么的。服务有点像灰色地带；如果服务以被动操作命名，例如ShippingService，那么服务处理的内容就很清楚了，但更好的名称可能是ShipmentDispatcher。我希望你明白了。

【讨论】：

【解决方案2】：

不要太拘泥于命名法；一般来说，服务为类提供一些东西以减少耦合，而管理器更通用——可能是一个跟踪其他对象和/或状态的类。

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

服务和管理器可能有助于在运行时将这些东西粘合在一起，并且这种命名法有助于将这些类与封装域逻辑的东西区分开来。

【讨论】：

【解决方案3】：

在您决定使用域模型模式的场景中（如果您想使用 DDD，显然），诸如验证、计算和业务规则之类的业务逻辑肯定构成了域模型的一部分（您的业务对象及其关系） )。

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

【讨论】：