我有一个带有应用服务的有界上下文，用DTO公开应用程序用例。
有界上下文还包括一个域服务，用于公开具有丰富域对象的域用例。 Application Service是域服务的“客户端”。
最后，存储库允许域对象的持久性。
域中存在其他有界上下文，拥有有界上下文的团队之间的关系是客户/供应商，因此团队可以根据相同的目标进行协调，并可以合作将所需的用例公开给其他有界的上下文。
在这种情况下，“客户有限的背景”应该连接到“供应商有界环境”吗？
“供应商有界上下文”是否可以直接访问存储“供应商有界上下文”的富域对象的存储库或域服务？ （在“客户有限的上下文”中使用ACL来屏蔽“供应商有界上下文”在域中泄露）。我不确定这种方法是否合适，因为域重构会破坏所有ACL并需要维护。我知道这是ACL的目标但是......
或者“消费者有限上下文”是否最好只连接到“供应商有界上下文”的应用服务，公共DTO暴露在哪里？ （不需要ACL）。我不确定这种方法是否合适，因为它强制应用服务模仿域服务仅用作接入点，即使用例显然是域用例。
有什么意见吗？有没有人尝试过这两种方法中的一种，有好/坏的经历？
我没有从Vaughn Vernon的书或Scott Millett的书中找到明确的答案。
答案 0 :(得分：1)
两个团队应合作为供应商BC定义API。不要只是直接耦合到其他BC应用程序服务甚至模型。
API通常被实现为REST API，但从您的问题来看，这听起来就像是在一个应用程序中集成了多个BC。如果是这种情况，那么您应该将API定义为接口库。
应对接口库进行版本化和记录。它应该由供应商团队维护，消费者团队根据他们的需求提出变更请求。
如果供应商BC有一个非常简单的模型，则只通过API公开域模型。在所有其他情况下，定义封装所需用例的应用服务是有意义的。然后，只有这些应用服务才会公开为API。