Domain driven design 如何在创建聚合和实体时集成有界上下文？

我试图将DDD原则与CQR一起应用，但在集成有界上下文时遇到了困难

让我们考虑市场域中的目录和计费上下文。我在公元前1世纪将产品概念建模为目录集合的实体，在公元前1世纪将其建模为集合

现在我有了这个“商家用户界面”，商家可以在其中将产品添加到他的目录中。进行此操作时，他将提供产品名称、说明和其他一些分类和定制数据，以及销售价格、折扣政策等

我应该如何在两种有限的环境中传达产品的创建？ 我考虑过以下方法，但没有一种适合我：

• 创建一个命令，收集商户通过UI提供的所有数据，然后让控制器或应用程序服务集成有界上下文并向每个上下文发送专用命令

• 将定价信息添加到目录BC并触发事件（或使用数据库触发器）以通知计费BC产品创建

什么是令人满意的替代方法

谢谢

这个怎么样

在目录上下文中，产品被建模为一个实体，这在我看来是正确的

在计费上下文中，产品可以是一个值对象，通过反腐败层从目录上下文转换而来。此产品模型中仅应包含计费所需的详细信息

如果在计费上下文中使用CQR，您可能会发现需要刷新查询模型。也就是说，创建一个新的产品价值对象。要做到这一点，我同意不需要事件通知。在接收到刷新其查询模型的消息后，计费上下文将访问目录上下文中的应用程序服务，目录上下文可能具有自己的CQRS体系结构或其他内容

我不确定为什么产品需要在计费上下文中是聚合的。产品是否需要在计费上下文中具有命令方法，或者它是否有自己的存储库

---

我猜您应该感谢自己避免在应用程序服务中组合上下文，尽管在某些情况下这可能是最好的主意。不过，一般来说，应用程序服务属于单个有界上下文。

谢谢您的回答。我不喜欢跨边界直接调用应用程序服务。这将导致两者之间的紧密耦合。但我猜上下文“A”中的事件可以被视为上下文“B”中的命令。这可以做到。感谢再次使用防腐蚀层来移除紧耦合。一个上下文不直接调用另一个上下文的应用程序服务，而是通过“端口和适配器”转换。目录上下文中的应用程序服务可能公开一个REST-ful服务，由计费上下文中的转换器实现调用。