我正在尝试将DDD原则与CQRS一起应用，并且我在整合有界上下文时遇到了问题。
让我们考虑市场领域中的目录和结算上下文。我将产品概念建模为BC省第一个目录聚合的实体，并作为后者的聚合。
现在我有了这个＆＃34;商家用户界面＆＃34;商家可以将产品添加到他的目录中。在这样做时，他将提供产品的名称，描述和其他一些分类＆amp;定制数据，以及它的销售价格，折扣政策等......
我应该如何在两个有界上下文中传达产品的创建？ 我考虑过以下几种方法，但对我来说都不合适：
创建一个单独的命令，收集商家通过UI提供的所有数据，然后让控制器或应用程序服务集成Bounded Contexts并为每个上传专门的命令
将定价信息添加到目录BC并触发事件（或使用数据库触发器）以通知Billing BC创建产品
什么是令人满意的替代方法？
由于
答案 0 :(得分：1)
这个怎么样？
在目录上下文中，产品被建模为实体，这似乎对我而言。
在“结算”上下文中，“产品”可以是“值”对象，通过反腐败层从“目录”上下文转换。只有计费所需的详细信息才应包含在此产品型号中。
如果在结算上下文中使用CQRS，您可能会发现需要刷新查询模型。也就是说，创建一个新的产品价值对象。要做到这一点，我同意需要事件通知。在收到刷新其查询模型的消息后，Billing上下文将访问Catalog上下文中的Application Service，该上下文可能具有自己的CQRS体系结构或其他内容。
我不确定为什么产品需要在结算上下文中成为聚合。产品是否需要在Billing上下文中具有命令方法，或者它是否具有自己的存储库？
我的猜测是你要感谢自己避免在应用服务中组合上下文，尽管在某些情况下它可能是最好的主意。但是，一般而言，应用程序服务属于单个有界上下文。