EventSourcing 和 DDD 實體事件

Question

我有一個使用 EventSourcing 的 DDD 項目。 目前有許多聚合根，其中許多都有實體的集合。 甚至更多 - 一些實體具有其他實體的集合。

問題：出於審計目的讀取 EventSourcing 事件日志。

問題：當實體被更新/創建/刪除時，在 EventStore 中保存事件的最佳方法是什么，記住所有這些事情：它們必須易於閱讀，版本，可能不適合這種情況，但通常粒度事件更可取，可能域事件將用於跨域通信。

1. 我是否應該在根流中將整個根以及其中的所有實體集合保存為 RootChangedEvent ？

2. 我是否應該僅將根流中已更新/創建/刪除的實體保存為 EntityChangedEvent/EntityCreatedEvent/EntityRemovedEvent

3. 我是否應該在根流中保存兩個事件 - 一個用於根 - RootChangedEvent 只有版本屬性 + 第二個用於實體，如果在 EntityChangedEvent 或整個實體中更改，則只有一個屬性，如果 EntityCreatedEvent 或只有 id 如果 EntityRemovedEvent （如何處理實體的實體是否創建/更新/刪除？）

這是我項目中的一個例子：

根 - 管道。

public class Pipeline : AggregateRoot<IPipelineState>

它具有實體集合 - public IList<Status> Statuses 。

每個狀態都有實體集合 - public IList<Logic> Logics 。

所有集合都可以存儲很多實體。 現在我會引發諸如 PipelineCreatedEvent、PipelineChangedEvent（不僅在 Pipeline 更改時，甚至在添加、更新、刪除狀態或邏輯時）和 PipelineRemovedEvent 之類的事件。

Answer 1

任何給定的聚合都應該有一個事件流，以避免競爭條件。 聚合是一個事務邊界。

在您的情況下，嘗試用商業術語而不是實體來表述系統中發生的事情：

1. 訂單創建 (orderId=123)
2. 添加訂單項（訂單 ID=123，'product1'）
3. 添加訂單項（訂單 ID=123，'product2'）
4. OrderItemRemoved (orderId=123, 'product1')
5. 訂單支付 (orderId=123)
6. OrderArchived (orderId=123)

這些事件是怎么發生的？ 使用 Order 所以 order 是您的聚合根，而 123 - 它的aggregateId。 您甚至可能不需要 OrderItems ，除非命令處理程序需要這樣做（例如，您不想為已刪除的項目發出 OrderItemRemoved 事件）。

您將有一個用於aggregateRoot 123 的事件流，並且在您處理PayOrder 命令時，沒有人可以添加和OrderItem。

重要的是要了解，您的事件越具有特定的業務，您以后使用域聚合和讀取模型的靈活性就越大。 請記住，您的事件是不可變的，並且會永遠存在！

OrderEntityChangedEvent (new Status = Paid) 意味着您的實體的特定結構OrderPaid事件假定除了某處有一個 Order Aggregate 根之外什么都不做。