架構模式: 事件溯源
問題
您已應用事件驅動的體系結構模式。為了可靠，服務必須在狀態發生變化時以原子方式發布事件。使用跨越數據庫和消息代理的分布式事務是不可行的。如何在狀態發生變化時可靠地/原子地發布事件？
解決方案
這個問題的一個很好的解決方案是使用事件源。事件采購將業務實體（例如訂單或客戶）的狀態保持為一系列狀態改變事件。每當業務實體的狀態發生變化時，都會在事件列表中附加一個新事件。由於保存事件是單個操作，因此它本質上是原子的。應用程序通過重放事件來重建實體的當前狀態。
應用程序將事件保留在事件存儲中，事件存儲是事件的數據庫。商店有一個用於添加和檢索實體事件的API。事件存儲的行為也類似於消息代理。它提供了一個API，使服務可以訂閱事件。當服務在事件存儲中保存事件時，它將被傳遞給所有感興趣的訂戶。
例子
下圖顯示了電子商務系統如何使用事件源來保持訂單。
應用程序將每個Order作為一系列事件持久存儲，而不是簡單地將每個訂單的當前狀態存儲為ORDERS表中的一行。CustomerService可以訂閱訂單事件並更新其自己的狀態。
有關更多詳細信息，請參閱Eventuate平台，它是基於事件源和CQRS的應用程序平台。有幾個示例應用程序
結果上下文
事件溯源有幾個好處：
- 它解決了實現事件驅動架構的關鍵問題之一，並且可以在狀態發生變化時可靠地發布事件。
- 因為它持久存在事件而不是域對象，所以它主要避免了對象 - 關系阻抗不匹配問題。
- 它提供了對業務實體所做更改的100％可靠審計日志
- 它使得實現在任何時間點確定實體狀態的時間查詢成為可能。
- 基於事件采購的業務邏輯由交換事件的松散耦合的業務實體組成。這使得從單一應用程序遷移到微服務架構變得更加容易。
事件采購也有幾個缺點：
- 這是一種不同的，不熟悉的編程風格，因此有一個學習曲線。
- 事件存儲很難查詢，因為它需要典型的查詢來重建業務實體的狀態。這可能是復雜而低效的。因此，應用程序必須使用命令查詢責任隔離（CQRS）來實現查詢。這反過來意味着應用程序必須處理最終一致的數據。
關聯模式
- 事件驅動的體系結構模式創建了對此模式的需求。
- CQRS通常用於事件溯源。