Oop 考虑到有界上下文之间的交互可能是“常见的权衡”。跛行开闭原理；？ 我正在实现有界上下文之间的交互，并且我发现它“某种程度上”削弱了开放的封闭原理，而我不确定，这是否是设计BCS的自然后果以及考虑或设计失败的共同权衡。

考虑一下BC商店，在那里你可以用购物车和一些物品创建订单。创建的订单由

OrderItem

s组成，每个订单包含各种类型的

ItemSpecification

值对象接口，如

ProductSpecification

或

FooServiceSpecification

，保护不变量并包含一些数据。创建订单时，将发出可由任何其他BC侦听的异步事件

该异步事件是无序创建的，并表示为（序列化的）OrderCreatedEvent对象，包含OrderDTO对象，所有这些对象都放在核心命名空间中，该命名空间与每个BC共享，因此任何BC都可以依赖于核心，但不能依赖于其他方式。到目前为止一切都很好，几乎：

OrderItemDTO必须包含接口

ItemSpecificationDTO

，每种类型的规范都需要实现该接口。我的

ItemSpecification

VO（与顺序中的任何其他VO/实体一样）有

toCoreDTO（）

方法，可以实用地实现简单的翻译，而且它也使得实现新的

ItemSpecification

相对困难，并且忘记了根据DTO实现。那可能没关系

但是其他收听该事件的BC呢？在每个BC中，此事件需要在其反腐败层中进行转换，BC可能只对某些类型的

ItemSpecificationDTO

感兴趣，并将其转换为各种值对象，这对特定BC非常重要

正如鲍勃叔叔用机智的语言谈论OCP：

您应该能够扩展系统的行为，而无需 修改该系统

但是当我实现新类型的

ItemSpecification

时，对于可能对这种新类型感兴趣的每一个BC，我需要专门将这种新类型从CoreDTO翻译成（好的，我可以为每个BC中的翻译编写一些抽象，所以我仍然只是添加代码，而不需要修改任何东西，比如添加if（$x instanceof x））。但是，通过添加新类型的

ItemSpecification

，我需要在其他BC中进行适当的扩展（甚至可能修改某些内容，因为我们并不生活在理想世界中）

---

我不知道该怎么想。这是整个DDD方法的缺点吗？或者可能是特性，因为在其他BCs中寻找需要进一步扩展的内容、位置和方式是由领域需求而不是技术问题驱动的？这似乎是对的。最后，我试着做领域驱动的设计：-），但在我看来，这也有点危险。我担心有一天我们会忘记更新一些其他BC，而一些不好的事情发生了。但这可能是因为我在领域专家的角色中也扮演了很大的角色，这种“恐惧”应该属于这个角色。我的问题是坐在两把椅子上还是我做错了什么？：-）

关于这个主题有很多有趣的细节，但我将在这里集中讨论有界上下文的一个特定方面

也就是说，它们被限制是有原因的。与中一样，模型/对这些上下文的理解之间应该有一个界限。两个上下文，即使它们是相关的，也应该对系统有不同的看法，即使对可能部分共享的数据也是如此

在我看来，您的“有界上下文”想要在同一个模型上工作。您甚至创建了一个“核心”模型，每个人都可以看到，而且显然必须能够理解。如果是这样的话，我认为你失去了拥有不同上下文的好处，你只是用一个模型创建了一个大应用程序

为了纠正这个问题，我认为您需要去掉任何中心/核心模型，并在不同的上下文/服务中使用“局部”（有界）模型。当您需要与其他组件通信时，您需要为这两个组件定义一个协议，由其中一方或双方指定

---

例如，购物车可能需要知道后端系统的产品id才能在那里创建订单。但是后端系统不需要知道购物车使用的模型就可以知道订单是关于什么的（在它自己的模型中）。

我不这么认为，因为在这个核心中，我只有用于异步事件的DTO，这些事件是为在有界上下文之间进行通信而发出的。此外，在每个BC中，监听该事件的任何一个都是反腐败层，将该核心事件DTO转换为其特定于域的VO，这样就不会将一个BC泄漏到另一个BC中。2） 标识-值对象，如包含uuid的UserId和3）一些非特定于域的有用抽象（类似AbstractCommandbus的东西会出现在那里）。。。你知道吗？显然我不知道你的具体情况，但是：1。通信和协议都很困难。它需要双方（或多方）同意。它应该是不变的，或者很少变化的。每次都应该向后兼容。这不是详细定义特定于域的实体的地方。3.非领域特定的东西应该在库中，可能是github上的开源，就像netflix一样。此外，反腐败层应该解决无法真正适应的遗留系统的问题。如果你控制了两边（看起来是这样），那么我就没有理由再增加一层了。同样，这只是我的观点，但我会尝试更彻底地分离这些系统。但我没有在Core中指定任何实体，只有DTO，它只是需要在OrderCreated事件中指定一组数据，就像用json序列化一样。关于非特定领域的事情，你是对的。关于反腐败层，好吧