介绍
这个问题是关于 DDD 和事件溯源,其中聚合中的实体(聚合根除外)具有事件生成行为。
例子
下面是我描述的情况的一个示例,我确定我想在聚合内的其他实体中封装一些逻辑。这可能涉及暂停对实际示例以及它是否是一个好模型的怀疑。:)
我正在尝试对DeliveryRun
聚合根 (AR) 建模,这是车辆执行交付的行程。在它离开之前,它必须有一个最新的DeliveryManifest
. 它的“最新性”向我表明,它是 AR 定义的一致性边界DeliveryManifest
内的一个实体。DeliveryRun
到目前为止还好。
我为此使用了 Event Sourcing 方法 - Greg Young教授并在Regalo 库中实施的方法。这意味着如果 AR ( DeliveryRun
) 没有任何行为,则它们实际上不需要任何实体(例如,aSalesOrder
可能没有SalesOrderLines
,因为它记录了诸如ItemsAdded
/之类的事件ItemsRemoved
)。
但是,围绕DeliveryManifest
. 具体来说,一旦首次请求清单,当项目被添加到交付时,需要创建清单的新版本。这意味着我们可以确保司机在没有可用的最新清单的情况下不会离开。
如果我要将逻辑封装在DeliveryManifest
对象内部(不会被序列化和存储;我们使用的是事件源,它不是 AR),我如何捕获事件?
我正在考虑的选项
事件是否应该由
DeliveryManifest
实体生成,但针对DeliveryRun
自身保存(然后需要知道如何将这些事件重播到DeliveryManifest
从事件存储加载时)?是否应该没有
DeliveryManifest
(可能作为数据结构除外)并且所有逻辑/事件都由DeliveryRun
?是否应该
DeliveryManifest
是它自己的 AR 并确保DeliveryRun
被告知当前清单的 ID?由于这将清单对象置于 的一致性边界之外DeliveryRun
,因此我需要构建一些事件处理来订阅DeliveryRun
与清单相关的更改,以便可以相应地更新/无效等。实现与 Udi 的 DomainEvents 模式类似的不同样式来捕获事件。这意味着更改 Regalo 库,尽管我认为它可以很容易地支持这两种模式。这将允许捕获聚合中所有实体生成的所有事件,以便针对 AR 保存它们。我需要考虑一个加载/重播的解决方案......