域服务是域模型的一部分吗？

Question

根据DDD，服务是否是域模型的一部分？ 如果我们用谷歌搜索“ ddd洋葱架构”，我们通常会看到最内层称为“域模型层”，第二层称为“域服务”，例如[dead link，NSFW不再]。 但是在https://en.wikipedia.org/wiki/Domain-driven_design和DDD书中，我们看到实体，价值对象和服务都表达了模型并且是模型元素。 如果实体，价值对象和服务都是领域模型的一部分，那么我们应该如何称呼洋葱的这两层：模型（实体+价值对象）和服务（就像我有时做的那样）？ 但是，如果全部都是域模型的一部分，则这种命名似乎并不准确。

Answer 1

域服务是域模型的一部分吗？

是的，但也没有。

在蓝皮书中，第五章介绍了域服务。 在实体和值类型之后。 埃文斯写道

在某些情况下，最清晰，最实用的设计包括在概念上不属于任何对象的操作。 除了强制问题外，我们还可以遵循问题空间的自然轮廓，并在模型中明确包含服务。

服务是作为接口提供的一种操作，在模型中是独立存在的，而没有封装任何状态。

接口是根据域模型的其他元素定义的。

但是，域服务的实现并不总是存在于域模型本身中。

在某些情况下，域服务实际上是充当服务提供者，需要将其连接到基础结构以执行其角色（例如，将消息发送到另一个进程）。 因此，域模型定义了提供者接口，将该接口的实现传递给它（例如，作为聚合根上方法的参数），然后模型决定是否/何时在该接口上调用方法。

实体和值对象能否对域服务的接口具有编译时依赖性？ 它们（域服务的实体，值对象和接口）是否在域模型的同一层中？

是的，是的。 例如，这是第7章中运输应用程序的在线示例 。

public interface RoutingService {
    List<Itinerary> fetchRoutesForSpecification(RouteSpecification routeSpecification);
}

现在，这个特殊的演示恰好使域服务保持在与模型不同的名称空间中，并使用应用程序服务将两者桥接 。

return routingService.fetchRoutesForSpecification(cargo.routeSpecification());

但是，将这一部分作为模型的责任也将是正确的。

return cargo.fetchRoutes(routingService);

查询为您提供了一些发挥的空间，因为您不必担心允许模型保护自己的不变性。 使用命令，后一种方法可以提供更好的封装

order.updateSalesTax(taxCalculatorService);

Answer 2

根据DDD，服务是否是域模型的一部分？

它是域层的一部分。 域服务封装了不能自然建模为值对象或实体的域逻辑。

在洋葱体系结构中，所有依赖项都向内。 值对象和实体不应对域服务有任何依赖关系。 领域服务取决于实体和价值对象。 该体系结构的核心是域层（值+实体+服务）。 这是DDD，是业务/问题域的抽象视图。 该层不依赖数据库，Web服务调用，SMTP和其他与基础架构相关的服务。

上面的一层是取决于域层的应用程序层。 应用程序层由应用程序服务组成，这些服务包含用于协调业务用例的应用程序逻辑。

下一层是基础结构层，它可以负责存储信息，日志记录，安全性，通知以及与其他有界上下文的集成的技术实现。 该层还使应用程序层可以通过Web服务或消息终结点使用。

为了避免这些层之间的紧密耦合，高层必须适应较低层的消息类型。 在这些层之间，您可以使用数据传输对象（DTO），这样就不会跨边界传递域对象（实体）。 另外，为了避免与特定技术（例如数据库）的紧密耦合，各层还通过接口进行通信。