实体 – DDD,CQRS,事件采购：实体来自哪里？

我对有利于CQRS&amp ;;的环境中实体的起源感到有些困惑.活动采购.为了使我的问题清楚,让我们采取以下着名的网上商店示例：

您可以将订单建模为聚合根.订单接受订单行,订单行本身由产品和数量定义.

由于订单行是在订单处理过程中构建的实体,因此产品的概念似乎也是一个实体.但产品甚至产品目录来自哪里？在我看来,在订单的有限上下文中没有像产品聚合根这样的东西.那么订单背景如何知道产品实体呢？它们是否在另一个有界的上下文中维护并以某种方式在订单上下文的读取存储中实现？

在包含Order的BC中,作为OrderLine的一部分,Product可能确实是一个值对象,由诸如ProductId,Name等值组成.

订单上下文不需要了解产品实体,因为订单行通常只包含简单的仅限价值的属性(productId / SKU,名称,数量和每个/项目的价格).因此,Order可以提供诸如此类的功能

void addOrderLine(ProductId productId, String productName, BigDecimal pricePerItem, int quantity).

它实际上与“订单”-BC无关,其中productId,productName等的这些值来自.

然而,在实践中,很可能这些价值可以从另一个有限的背景中获得,比如“产品”-BC,它负责库存管理等.

让UI协调这些BC是很常见的：

> UI(例如,客户的网上商店)从“Product-BC”加载产品及其价格>用户将产品放入购物篮(为简单起见,我们假设这也是“Order-BC”).因为,UI触发由“订单”-BC处理的命令,例如AddToShoppingBasketCommand(productId,productName,quantity,price).>当用户想要下载当前购物的订单时,它会触发PlaceOrderCommand.> PlaceOrderCommand的命令处理程序获取当前购物篮并构造相应的Order;对于每种产品,它所需要的只是已经在购物篮中列出的产品的相应属性(最初位于AddToShoppingBasketCommand中).请注意,它不需要了解Product-BC中的Product实体的概念.