domain-driven-design - DDD 组合多个有界上下文

Question

我想要你关于有界上下文集成的建议。
我有一个用例，它让我陷入困境:

我有 Contract 的有界上下文管理。我可以将各方(例如各种外部组织)添加到契约(Contract)中。为每一方选择他们的投资/贡献(例如:总额的 10%)。 SO 契约(Contract)管理有两个方面:一种是行政性的(添加方，管理倍数日期，...)另一种是财务性的(计划跨越多年的捐款，检查捐款消耗，...)。

我还有一个 Budget 的有界上下文.此上下文负责组织级别的费用管理。示例:服务 A 将具有 1000 欧元的费用容量。我们可以计划一个预算，然后每个组织方可以消费，购买东西，他们的部分。为了建立预算，负责企业预算的用户可以直接拨款或整合年度契约(Contract)财务组件 .当我们在预算内集成契约(Contract)部分时，我们会卡住预算内的数据，即将货币数据从一个数据库表复制到另一个数据库表中(添加一些审计信息)。我们有一个数据库。

这是我挣扎的最后一部分。每个有界上下文都是一个专用的应用程序。在 budget应用程序，在将契约(Contract)部分集成到当前预算中后，我需要显示预算明细行。不幸的是，在预算表中，我只有金钱数据，而没有关于契约(Contract)的一些基本信息(对象、引用……)。

我在想什么:

有时在有界上下文之间复制数据也不错。我卡住了契约(Contract)的金钱部分。我还可以卡住/复制契约(Contract)的对象和引用。那么查询只会发生在 budget context 内部.但这里的问题是数据重复。今天我需要对象/引用，如果明天我需要更多字段......我将需要域事件管理来保持契约(Contract)/预算之间的数据同步。

查询预算，每行查询一个 contract将返回所需数据的服务。这使每个上下文保持自治，但我需要发出大量数据库请求来丰富 budget details line对象。

只需在数据库级别进行一个连接，我们就可以完成这项工作。这里的耦合怎么样？这是一个简单的解决方案，也是我们今天正在做的事情(它是一个共享内核吗？)。看来我们不能改变contract结构而无需重建预算应用程序。我没有上下文之间的程序化契约(Contract)。

我的问题是:

如何构建需要来自 budget context 的数据的 UI 屏幕每个细节行都需要来自 contract context 的数据?

旁注:

也许上下文识别和边界从一开始就是错误的(这是一个遗留设计)。

我想要的是保持上下文分离(松散耦合)。如果我们可以在上下文之间指定设计契约，那么维护会更容易(或者不是？)。

我没有看到如何集成这些上下文(我需要重新读取共享内核、ustream/下游等)。

Answer 1

这是一个额外的、不同的有界上下文。它与现有的有界上下文有一些重叠，这很容易让你走上错误的道路(合并上下文或将额外的行为放在不属于它的上下文中)。

有时可以在不同的有界上下文中拥有引用相同逻辑实体的实体，但它们只是为了特定场景(例如在特定上下文中)的目的而提供该实体的不同 View 。

电子商务场景就是一个很好的例子。在大多数电子商务应用程序中，您都会有 Order 的概念。 ，但没有关于“订单”是什么的全局、明确的概念。在财务方面 - 订单只是一张发票。在履行环境中 - 订单只是一个装箱单和一个将 cargo 发送到的地址。在营销环境中 - 订单代表有关客户感兴趣的一小部分情报，可用于 future 的有针对性的营销。

有一条贯穿所有这些实体的共性线索，但您可能会看到至少 3 个独立的 Order类，每个类都在上下文中捕获顺序的概念。

所以在你的情况下，你有 Contract 的有界上下文以及 Budget 的有界上下文.在我看来，你现在有另一种看待这些实体的方式，特别是它们相互交互的方式。这是实体的新 View ，可以在其自己的上下文中捕获的 View 。这个新的上下文可能会有自己的 Contract和 Budget实体，并且将与 Context 和 Budget 上下文重叠，但其中还会有其他关系和行为，这在其他上下文中没有意义。

这是一个很难解释的想法:) 前段时间我在这里写了一个类似问题的答案:DDD - How to design associations between different bounded contexts