域服务应公开哪些API？

Question

启发我自己沃恩·弗农https://github.com/VaughnVernon/IDDD_Samples，在决定域服务应具有的API时我感到困惑：

• 域服务DomainService1使用域DomainService2来执行部分业务逻辑。然后根据Repository1

的调用结果过滤DomainService2.myMethod的结果

• DomainService2需要的数据不是位于MyCurrentBoundedContext而是位于ForeignBoundedContext

我们通常的方法是像这样实现独立的Service2用例：

1. 我们将在DomainService2.myMethod签名中包含执行逻辑所需的域对象
2. 我们将编写一个ApplicationService2，它将为DomainService2提供一个入口，并使用另一个服务DomainService3，该服务负责从ForeignBoundedContext
3. 我们通常将DomainService3实施为AntiCorruption Layer，就像沃恩·弗农（Vaugh Vernon）在其TranslatingCollaboratorService中所做的那样

现在我们的问题在于将这种模式应用于设计DomainService1，因为它包含重要的领域逻辑：

1. 我们可以将DomainService1本身包装到ApplicationService1中，从中我们首先调用ApplicationService2，然后将其结果向下传递给所有{ 1}}。这种方法的缺点是DomainService1 API应该被调用以包含仅由于DomainService1通常使用DomainService1来执行工作的一部分而需要的参数

2. 我们可以删除DomainService2，更改ApplicationService2的签名（因此更改我们常用方法的第一点），并且仅包含id。然后，我们将创建一个DomainService2的实现，该实现位于基础结构软件包中，并将使用DomainService2，以反映“旧” DomainService3的行为。这似乎比更改DomainService1的签名更自然，但是我们对在域服务实现中放置与在应用程序服务中放置的相同逻辑的想法不满意。

ApplicationService和域服务实现之间的边界在哪里？