entity - DDD、CQRS、事件溯源 : Where do entities come from?

Question

我对利用 CQRS 和事件溯源的环境中实体的起源有些困惑。为了让我的问题更清楚，让我们以以下著名的网上商店为例:

您可以将订单建模为聚合根。订单接受由产品和数量定义的订单行。

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

Answer 1

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

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

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

它实际上与“订单”-BC 无关，其中这些值为 productId , productName等起源于。

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

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

UI(例如，客户的网上商店)从“Product-BC”

加载产品及其价格。

用户将产品放入购物篮(为简单起见，我们假设这也是“订单-BC”)。因为，UI 会触发诸如 AddToShoppingBasketCommand(productId, productName, quantity, price) 之类的命令。由“订单”-BC 处理。

当用户想要为当前的购物 basked 下订单时，它会触发 PlaceOrderCommand .

PlaceOrderCommand 的命令处理程序获取当前购物篮并构造一个对应的 Order ;它所需要的只是，对于每个产品，已经在购物篮中列出的产品的各自属性(并且最初在 AddToShoppingBasketCommand 中)。请注意，它不需要知道 Product 的概念。来自 Product-BC 的实体。