领域驱动设计：管理器和服务

Question

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

- ryudice

Answer 1

尽可能具体地命名。通常，我会避免使用“Manager”这一名称，因为其含义非常模糊。

典型的业务逻辑执行者/名词包括Validators（验证器）、Rules（规则）、Providers（提供程序）、Supervisors（监管员）、Importers/Exporters（导入/导出程序）、Serializers（序列化程序）、Processors（处理交易）以及Repositories（最后一个你已经有了）。如果单个类执行多于一种功能，则应该将其拆分成子类。

你问了一个问题，“这些类负责什么？”事实上，这就是关键所在。SomethingManager这样的命名对你毫无意义。另一方面，像OrderValidator和CustomerHistoryExporter这样的名称相当清楚地说明了类的功能。服务属于灰色地带；如果服务以被动动作命名，例如ShippingService，那么它处理的内容就相当明确，但更好的名称可能是ShipmentDispatcher。希望你能理解我的想法。

- Aaronaught

Answer 2

不要过分纠结于术语，通常服务为类提供某些内容以降低耦合度，而管理器则更为普遍——可能是跟踪其他对象和/或状态的类。

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

服务和管理器可以在运行时帮助将这些东西粘合在一起，并且该术语有助于区分这些类与封装领域逻辑的内容。

- Jay

Answer 3

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

一个好的通用参考资料也可以为您提供Martin Fowler的书《企业应用架构模式》'Patterns of Enterprise Application Architecture'。

(Note: The link in the text is kept in English as it is a book title.)

- Michael Ulmann