Design patterns 有界上下文规则编排

我的银行核心领域分为两个不同的边界背景BC1和BC2。这些业务连续性协议涉及非常具体的业务规则和流程（债务回收的定制协议，以及具有法律义务的行政债务）。BC1和BC2通过CRM的Web服务访问。客户不能同时拥有自定义协议和债务计划，并且每种情况都排除了另一种情况。因此，我们需要协调这两种类型的流程（更准确地说，我们需要在每一个BC中强制执行允许在双方执行的操作）

你将如何安排它们？您是否会在BC2域模型中注入一点BC1知识，反之亦然，或者您认为我们应该依靠第三个BC（BC3）来协调系统，并了解这两种业务知识，例如通过第三个Web服务？我们只需要知道客户是否与该公司签订了协议，或者该公司是否负有正式和法律责任

---

您认为让BC1了解BC2业务“一点”是否违反DDD原则？如果是orchestrator或代理，您会使用WebServices还是SharedKernel？SharedKernel与WebService的优缺点是什么？

如果我理解正确，您只想从一个BC查询另一个BC，以确定是否允许某些操作

从另一个BC调用另一个服务是很常见的，就像使用外部API一样。

---

所以我会这样做。

拥有一个BC的全部意义是保持事物的分离。BC1和BC2是陌生人。如果他们使用同一种语言，他们应该是公元前一世纪。两个BC都不需要对另一个了解“很少”或更多。另外，查询另一个BC只是以后自找麻烦

两个BC都可以通过域事件进行通信。当一个BC更改域事件（DTO）时，将发布一个域事件（DTO），另一个BC可以处理它，在本地（在其BC内）存储它所需的数据（在您的情况下，这意味着存储客户是否有自定义协议/负债计划或该BC执行其工作所需的其他内容）。这样，每个BC只使用它自己的模型，并且是自治的

---

将BC视为远程服务是不可取的，因为您只需将BC1与BC2耦合，这会损害可维护性、性能、可用性和可扩展性。

我不会这样做。请看我的答案。我认为这取决于BC的预期用途。例如，支持/通用子系统（标识和访问）。显然，这种类型的BC不应该存在于荒岛上，而是向任何下游客户提供服务。@Marco身份和访问等通用基础设施组件与域无关，它们是应用层的一部分。OP有一个领域建模问题，因为它需要来自不同BCST的业务规则。事实并非如此。BC就像一个独立的应用程序，从你的应用程序中调用外部应用程序并没有禁忌症。阅读DDD中关于有界上下文之间关系的章节。BC之间的通信有很多模式：共享内核、客户/供应商、墨守成规者、ACL等。@Rafałużyński“BC就像是单独的应用程序，从应用程序调用外部应用程序没有禁忌症”嗯。。。不，我不需要读章节，我有实践经验。