domain-driven-design - DDD 限界上下文集成 - 应用程序服务与领域服务与存储库

Question

我有一个应用服务的限界上下文，通过 DTO 公开应用用例。

限界上下文还包括一个域服务，它使用丰富的域对象公开域用例。应用服务是领域服务的“客户端”。

最后，存储库允许域对象的持久化。

域中存在其他限界上下文，并且拥有限界上下文的团队之间的关系是客户/供应商，因此团队会对齐同一目标，并且可以合作将所需的用例公开给其他限界上下文。

在这种情况下，“客户有界上下文”应该在哪里连接到“供应商有界上下文”？

“供应商限界上下文”是否可以直接访问存储库或公开“供应商限界上下文”的丰富领域对象的领域服务？ (在“客户有界上下文”中使用 ACL 可以防止“供应商有界上下文”在域中泄漏)。我不确定这种方法是否好，因为域重构会破坏所有 ACL 并需要维护。我知道这是 ACL 的目标，但是......

或者“消费者限界上下文”是否更适合仅连接到公开 DTO 的“供应商限界上下文”的应用程序服务？ (不需要 ACL)。我不确定这种方法是否好，因为它强制应用程序服务模仿领域服务，仅作为访问点，即使用例显然是领域用例。

有什么意见吗？有没有人尝试过这两种方法中的一种，但有好的/坏的体验？

我没有从 Vaughn Vernon 的书或 Scott Millett 的书中找到明确的答案。

Answer 1

这两个团队应该合作为供应商 BC 定义一个 API。不要直接耦合到其他 BC 应用服务甚至模型。

该 API 通常作为 REST API 实现，但从您的问题来看，您似乎正在将多个 BC 集成到一个应用程序中。如果是这样，那么您应该将 API 定义为接口(interface)库。

接口(interface)库应该进行版本控制和记录。它应该由供应商团队维护，消费者团队根据他们的需要提出变更请求。

如果供应商 BC 的模型非常简单，则仅通过 API 公开域模型本身。在所有其他情况下，定义封装所需用例的应用服务是有意义的。然后，只有这些应用程序服务会作为 API 公开。