我希望能够请教您关于有界上下文集成的建议。我有一个使用案例让我陷入了困境：
- 我有一个有界上下文用于合同管理。我可以向合同添加各种各样的外部组织作为参与方（例如）。对于每个参与方，选择他们的投资/贡献（例如总数的10%）。因此，合同管理是双重的：一方面是行政管理（添加参与方，管理多个日期等），另一方面是财务管理（计划跨越多年的贡献，检查贡献消耗等）。
- 我还有另一个有界上下文用于预算。这个上下文负责组织层面的费用管理。例如：服务A将拥有1000欧元的费用容量。我们可以计划预算，之后每个组织方都可以消费，购买东西，他们的那部分。为了构建预算，负责企业预算的用户可以直接分配资金或集成年度合同财务组件。当我们在预算中集成合同部分时，我们会冻结预算内的数据，即将货币数据从一个数据库表复制到另一个数据库表中（添加一些审计信息）。我们只有一个数据库。
正是最后一部分让我苦恼。每个有界上下文都是一个专用的应用程序。在预算应用程序中，在当前预算中集成合同部分之后，我需要显示预算详细信息行。不幸的是，在预算表中，我只有货币数据，而没有关于合同的基本信息（对象、参考等）。
我的想法是：
- 有时在有界上下文之间复制数据并不是坏事。我冻结了合同的货币部分。我还可以冻结/复制合同的对象和参考。然后查询将仅在预算上下文内进行。但是问题在于数据复制。今天我需要对象/参考，如果明天我需要更多字段……我将需要领域事件管理来保持合同/预算之间的数据同步。
- 查询预算，并为每个行查询
contract服务，该服务将返回所需的数据。这使得每个上下文都是自治的，但是我需要进行大量数据库请求来丰富预算详细信息行对象。 - 只需在数据库级别进行一次连接，我们就可以使其正常工作。这里的耦合如何？这是简单的解决方案，也是我们今天所做的（这是共享内核吗？）。似乎我们无法承受在不重建预算应用程序的情况下更改合同结构。我没有上下文之间的编程合同。
我的问题是：
我如何构建此UI屏幕，需要从预算上下文获取数据，并且每个详细信息行都需要从合同上下文获取数据？
附注：
- 也许从一开始就错了上下文识别和范围（它是一个旧的设计）。
- 我希望将上下文保持分开（松耦合）。如果我们可以在上下文之间指定设计契约，维护会更容易（或者不是吗？）。
- 我没有看到如何集成这些上下文（我需要重新阅读共享内核、上游/下游等）。