事件源核心概念

事件溯源介紹

在開始時（0:00），Derek討論了關於事件溯源及其相關核心概念的混淆。他將事件溯源定義為不僅是"捕捉當前狀態"，而是儲存事件——記錄您的領域模型中發生的每個變更於僅追加日誌中。

這樣，您就能維持您的系統狀態變更的完整歷史。 與其僅持久化最終狀態，您應持久化反映業務邏輯的事件。

事件：捕捉業務事實

在0:33時，Derek解釋了事件的本質。 一個事件代表了系統內已經發生的事情——一個業務事實。 例如，"產品接收"事件將包含接收的數量和日期。

Derek強調，當您儲存事件時，它們必須使用反映過去時態的命名規則命名，例如"產品已運送"或"庫存已調整"。 在事件模式中，您可能會有諸如public Guid Id、public string Name和時間戳之類的欄位。

每個事件也應有一個唯一的識別碼，這對於僅追加儲存系統很重要，在這裡您是將事件追加到事件流中的。

事件流：組織事件

在2:02時，Derek轉到了事件流的主題。 他將其與關係型資料庫表做比較，但解釋說在事件溯源中，所有與一個領域物件（如某個庫存項目）相關的事件都屬於同一個事件流。

每個事件流都連接到一個特定的實體——通常由public Guid Id和string Name定義。 例如，一個具有SKU ABC123的產品將有自己的流，包含接收或運送等已持久化的事件。

Derek建議，在建模這些時候，應考慮匯總根與領域物件，借鑒領域驅動設計概念。

建模生命週期——不論是短暫的還是長期的——有助於優化流的數量和大小。 這對於提升複雜系統的性能至關重要。

投影和讀模型

在4:12時，Derek介紹了投影和讀模型。 由於您的事件溯源系統捕捉的是事件而不僅是當前狀態，您必須重播事件來回答諸如"當前庫存數量是多少？"這樣的問題。

為了建立讀模型，您需要處理來自流的事件。 例如，使用private void Apply(Event e)或類似的方法，根據每個事件型別的事件處理器來增加或減少庫存。

Derek展示了如何在文件資料庫或關係型資料庫中構建讀模型——可能一個投影僅顯示手頭的數量，另一個顯示運送歷史。

這反映了命令查詢責任分離（CQRS）：將寫操作（命令）與讀操作（查詢）分開。

寫模型的投影

在6:48時，Derek展示了如何在寫作端也應用投影。 這對於在允許行動之前驗證行動至關重要。

在一個命令處理器中，運送產品之前，您需要驗證是否有足夠的數量。 Derek使用諸如private void Apply(Listevents)這樣的方法來重建必要的狀態。

像public int Version這樣的欄位有助於跟蹤流水的發展，確保最終一致性。

這種實際實施有助於在處理新事件時執行業務邏輯，確保您的系統僅在有效狀態轉換時進行操作。

訂閱：對新事件的反應

在8:01時，Derek討論了訂閱。 訂閱允許事件消費者監聽新事件並作出響應。

例如，一個投影器可能會訂閱一個事件流，並在看到"產品已運送"事件時更新讀模型。 或者，一個發布者可能會監聽事件並將它們發布到外部系統如RabbitMQ或Kafka，與其他服務進行整合。

Derek描述了訂閱不僅用於更新內部模型，還用於在獨立事件系統中進行資料分發，保持最終一致性。

這顯示了事件驅動架構的另一個主要好處：您的服務可以保持最終一致性但可以獨立擴展。

核心概念回顧

在9:21時，Derek總結了核心概念：

• 事件捕捉事實。

• 事件流按實體組織事件。

• 投影將流轉換為可查詢的讀模型或可操作的寫模型。

• 訂閱允許服務作出響應並相應更新。

他強調您在僅追加日誌中持久化事件，保持審計跟踪，並在必要時重播事件。

快照和優化

在9:39時，Derek談到了快照。 雖然經常與事件溯源一起討論，但他澄清快照是一種性能優化，而不是核心要求。

快照通過定期保存部分狀態來減少重播所有事件的開銷，但完整的歷史仍然存在於僅追加日誌中。

事件溯源與事件驅動架構的關鍵區別

在10:00時，Derek警告一個常見的誤解：事件溯源和事件驅動架構是不同的！ 像Kafka這樣的工具幫助資料分發，但真正的事件溯源專注於作為不可變審計跟踪記錄領域事件。

瞭解這一區別在將事件溯源整合到您的複雜系統中時至關重要。

結論

透過觀看 Derek Comartin 的影片，很清楚事件溯源是關於記錄每次變更作為事件，而不僅僅是最終狀態。 通過在僅追加儲存系統中儲存事件，您構建了一個豐富的事件模式，提供審計跟踪、彈性的事件查詢以及強大的命令查詢責任分離支援。

無論您是在.NET Core中處理C#事件溯源或其他任何平台，Derek關於核心概念、事件處理器、私有集、保護集及在模型中應用像private void Apply()的結構化解釋極具價值。

如果您正在致力於構建一個有彈性的領域模型、改進您的儲存系統，或者建立具有如最終一致性等多種優勢的複雜模式，研究Derek的方法是必須的。一定要看看他YouTube頻道上的更多有見地的影片。