在DDD中，域服务是否本质上仅仅是门面和/或中介模式？

在域驱动设计中，域层可以具有多个（传统）服务。例如，对于用户域，我们可能有：

• 一个UserFactory，它以不同的方式构建User对象
• 一个用户存储库，负责与基础结构层中的持久性服务进行交互

域层中的UserService是仅仅是这两个服务和基础结构层的中介者和/或Facade，还是它还有更多内容？

Domain services 用不是的最好的描述：

• 他们既不是也不Entities是Aggregate roots
• 他们不是 Value objects
• 所携带的领域知识并不自然地仅 适合一项Entity或一项 Value object

一个a的例子Domain service是Saga/Process manager：它协调了一个长期运行的过程，涉及多个Aggregate roots，可能来自不同的Bounded contexts。

就是说，什么是什么Domain service以及如何实现是两个正交的事情。

域层中的UserService是仅仅是这两个服务和基础结构层的中介者和/或Facade，还是它还有更多内容？

可以使用设计模式来实现某些域服务，例如，UserRepository（由中定义的接口Domain layer和中的具体实现组成Infrastructure layer） 。其他域服务则不是。Facade

除了必须不要依赖其他层（和SOLID）的重要规则外，没有关于如何实现它们的硬规则。Domain layer

我看到DDD中的服务是依赖倒置的结果。

如果要使用“普通”依赖关系，则域代码将调用数据库以保存或查询创建实体的实体或工厂，该实体或实体与数据库或外部服务或某种其他基础结构代码绑定在一起。

但这不是域代码应有的方式。域代码不应依赖于基础结构代码。由于这种依赖性使测试和可能的重用变得更加困难。这就是为什么您要反转该依赖关系的原因。您使基础结构代码取决于域代码。为此，您需要引入一个抽象。定义域代码预期由基础结构实现的行为的抽象。

而DDD中的服务就是这种抽象。在大多数情况下，对于域代码，那些服务应该是纯接口。实现应该在基础结构代码中进行，该代码依赖于这些接口。