限界上下文规则编排答案

【问题标题】：Bounded Contexts Rules Orchestration限界上下文规则编排
【发布时间】：2015-05-26 05:58:17
【问题描述】：

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

你会如何编排它们？您是否会在 BC2 域模型中注入一点 BC1 的知识，反之亦然，或者您认为我们应该依赖可以编排系统的第三个 BC（BC3），并且会了解业务知识，并通过例如第三个 WebService ？我们只需要知道客户是否与公司签订了协议，或者是否有正式和合法的债务。

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

【问题讨论】：

标签： design-patterns domain-driven-design business-rules

【解决方案1】：

拥有 BC 的全部意义在于将事物分开。 BC1 和 BC2 是陌生人。如果他们共享语言，他们应该是一个 BC。 BC 不需要知道对方的“很少”或更多。同样查询另一个BC只是以后找麻烦。

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

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

【讨论】：

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

【解决方案2】：

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

从另一个 BC 调用另一个服务是很常见的，就像使用外部 API 一样。所以我会这样做。

【讨论】：

我不会。看我的回答。