问考虑到有界上下文之间的交互可能会“削弱开放封闭原则”，这是一种常见的权衡吗？

EN

我正在实现有界上下文之间的交互，我发现它“某种程度”削弱了开放封闭原则，我不确定它是设计BCs的自然结果，还是考虑到共同的权衡，还是我的设计失败。

考虑一下BC商店，您可以在那里用一些商品创建购物车外订单。创建的顺序由OrderItem组成，每个顺序包含ProductSpecification或FooServiceSpecification等各种类型的ItemSpecification值对象接口中的一种，保护不变量并包含一些数据。在创建Order时，发出任何其他BC都可以侦听的异步事件。

异步事件按顺序创建，并表示为(序列化的) OrderCreatedEvent对象，包含OrderDTO对象，所有对象都放在与每个BC共享的核心命名空间中，这样任何BC都可以依赖Core，而不是依赖其他方式。到目前为止一切都很好，几乎：

OrderItemDTO必须包含接口ItemSpecificationDTO，这需要为每种类型的规范实现。我的ItemSpecification VO (与其他所有VO/Entity有序的)一样，具有toCoreDTO()方法，能够实现简单的翻译，同时也使得实现新的ItemSpecification相对困难，而忘记了按DTO的实现。可能没什么关系。

但是，其他收听这一事件的不列颠哥伦比亚省呢？在每个BC中，这个事件都需要在它的AntiCorruption层中进行翻译，而BC可能只对某些类型的ItemSpecificationDTO感兴趣，并将它们转换为各种值对象，这对于特定BC非常重要。

正如鲍勃叔叔在谈到OCP时所说的那样：

您应该能够扩展系统的行为，而不必修改该系统。

但是当我实现新类型的ItemSpecification时，对于可能对这种新类型感兴趣的每一个BC，我都需要从CoreDTO中具体地翻译这个新类型(好的，我可以为每个BC中的翻译编写一些抽象，所以我仍然只是添加代码，而不改变添加if($x instanceof X)之类的东西)。但是，通过添加新类型的ItemSpecification，我需要在其他BCs中进行适当的扩展(甚至修改一些东西，因为我们并不生活在理想的世界中)。

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