DDD,CQRS,事件采购:实体来自哪里?

Pat*_*hen 5 entity domain-driven-design cqrs event-sourcing

我对在利用CQRS和事件采购的环境中实体的起源感到有些困惑.为了使我的问题清楚,让我们采取以下着名的网上商店示例:

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

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

Ale*_*ger 3

在包含它的 BC 中,Order可能确实是这样的情况Product,作为 的一部分OrderLine,是一个值对象,由诸如 等值组成ProductIdName

订单上下文不需要了解产品实体,因为订单行通常只包含简单的纯值属性(productId/SKU、名称、数量和每件商品的价格)。因此,Order可以提供诸如

void addOrderLine(ProductId productId, String productName, BigDecimal pricePerItem, int quantity).
Run Code Online (Sandbox Code Playgroud)

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

然而,在实践中,这些值很可能可以从另一个有界上下文中获得,例如负责库存管理等的“产品”-BC。

让 UI 编排这些 BC 是很常见的:

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