限界上下文规则编排
Bounded Contexts Rules Orchestration
我的银行业务核心域分为 2 个不同的限界上下文 BC1 和 BC2。这些 BC 处理非常具体的业务规则和流程（债务追回的定制协议，以及具有法律义务的行政债务）。 BC1 和 BC2 通过 Web 服务从 CRM 访问。客户不能同时拥有自定义协议和债务计划，并且每一种情况都排除另一种情况。因此，我们需要协调这两种类型的流程（更准确地说，我们需要在每个 BC 中强制执行双方都允许的操作）。
你会如何安排它们？您会在 BC2 域模型中注入一些 BC1 的知识，反之亦然，还是您认为我们应该依赖第三个 BC (BC3) 来编排系统，并且了解这两种业务知识，并通过第三个 WebService 例如？我们只需要知道客户是否与公司有协议，或者是否正式合法地欠债。
你认为让BC1知道"a little"BC2的业务违反DDD原则吗？如果是编排器或代理，您会使用 WebServices 还是 SharedKernel？ SharedKernel 与 WebServices 的优缺点是什么？
如果我没理解错的话，您只是想从一个 BC 查询另一个 BC 以确定是否允许某些操作？
从另一个 BC 调用另一个服务很常见，就像使用外部 API 一样。
所以我会那样做。
拥有 BC 的全部意义在于将事物分开。 BC1和BC2是陌生人。如果他们共享语言，他们应该是一个 BC。 BC 都不需要知道 "little" 或更多关于对方的信息。还查询另一个BC，那是以后自找麻烦
两个 BC 都可以通过领域事件进行通信。当一个 BC 更改域事件 (DTO) 时发布，另一个 BC 可以处理它，在本地（在其 BC 内）存储它需要的数据（在您的情况下，这意味着如果客户有自定义 agreement/indebtedness 计划或该 BC 开展工作所需的其他事项）。这样，每个 BC 只能使用它自己的模型并且是自治的。
将 BC 视为远程服务是不可取的，因为您只是将 BC1 耦合到 BC2，这会损害可维护性、性能、可用性和可伸缩性。
我的银行业务核心域分为 2 个不同的限界上下文 BC1 和 BC2。这些 BC 处理非常具体的业务规则和流程（债务追回的定制协议，以及具有法律义务的行政债务）。 BC1 和 BC2 通过 Web 服务从 CRM 访问。客户不能同时拥有自定义协议和债务计划，并且每一种情况都排除另一种情况。因此，我们需要协调这两种类型的流程（更准确地说，我们需要在每个 BC 中强制执行双方都允许的操作）。
你会如何安排它们？您会在 BC2 域模型中注入一些 BC1 的知识，反之亦然，还是您认为我们应该依赖第三个 BC (BC3) 来编排系统，并且了解这两种业务知识，并通过第三个 WebService 例如？我们只需要知道客户是否与公司有协议，或者是否正式合法地欠债。
你认为让BC1知道"a little"BC2的业务违反DDD原则吗？如果是编排器或代理，您会使用 WebServices 还是 SharedKernel？ SharedKernel 与 WebServices 的优缺点是什么？
如果我没理解错的话，您只是想从一个 BC 查询另一个 BC 以确定是否允许某些操作？
从另一个 BC 调用另一个服务很常见，就像使用外部 API 一样。 所以我会那样做。
拥有 BC 的全部意义在于将事物分开。 BC1和BC2是陌生人。如果他们共享语言，他们应该是一个 BC。 BC 都不需要知道 "little" 或更多关于对方的信息。还查询另一个BC，那是以后自找麻烦
两个 BC 都可以通过领域事件进行通信。当一个 BC 更改域事件 (DTO) 时发布，另一个 BC 可以处理它，在本地（在其 BC 内）存储它需要的数据（在您的情况下，这意味着如果客户有自定义 agreement/indebtedness 计划或该 BC 开展工作所需的其他事项）。这样，每个 BC 只能使用它自己的模型并且是自治的。
将 BC 视为远程服务是不可取的，因为您只是将 BC1 耦合到 BC2，这会损害可维护性、性能、可用性和可伸缩性。