事件溯源域事件（拆分事件）答案

【问题标题】：Event sourcing domain events (split events)事件溯源域事件（拆分事件）
【发布时间】：2022-10-23 21:53:41
【问题描述】：

我有一个问题，我找不到任何答案。场景看起来像，我有一个产品，它有几个字段，如名称、描述、imageLink 等。当我将它保存到事件存储并且当我想恢复聚合时，我有一个事件 ProductRegistered 与所有这些字段此事件来自事件存储并加载到聚合。当我进行更新时，我有另一个事件 ProductUpdated ，它还包含所有字段，但这是一个技巧，它只保存已修改的字段。问题是当我想修改聚合并删除或添加任何属性时，它会引发异常。所以我读到了它，解决方案是将这两个大事件拆分成更小的事件，我的问题是我应该如何拆分它？每个字段的事件。因为从端点用户可以传递 6 个值。

例如，当我注册产品时，我应该创建如下事件：ProductRegistered（仅使用产品 ID）、ProductNameChanged（使用产品名称）等等？

【问题讨论】：

你可以有类似ProductPropertyChanged(string PropertyName, object oldValue, object newValue) 的东西，而不是每个属性都有一个事件。
你能详细说明一下吗？
leanpub.com/esversioning
此外，ProductChanged 或 ProductNameChanged 不会告诉您任何有关初始意图的信息。询问此产品更改的原因，并在事件名称中明确说明。这将帮助您举办更多面向业务的活动，从业务角度来看，这些活动具有一定的意义。

标签： c# domain-driven-design event-sourcing

【解决方案1】：

一般来说，最佳实践是捕捉正在发生变化的整体背景以及原因，因为这样做有助于这些事件的下游消费者采取行动，而无需尝试重建（可能不完美）该背景。由于事件溯源往往意味着 CQRS 和至少与写入模型一样多的读取模型，因此更复杂的写入模型（即要处理的更多类型的事件）以换取不太复杂的读取模型（特别是如果读取模型可以忽略他们不关心的事件类型）通常是值得进行的交易。

聚合的字段（更不用说取决于该聚合的任何特定读取模型的字段）与事件的字段之间也没有必然的关系：事件的字段应该描述更改的含义，而聚合的字段在写入模型只是捕获验证未来更改所需的内容：如果imageLink 的值从不影响更新name 的命令是否被接受，反之亦然，那么绝对不需要imageLink和name 是相同的聚合（例如，您可以有两个不同的聚合，其中相关标识符跟踪产品的名称和图像链接）。

【讨论】：