事件驅動系統中不同類型的事件

事件驅動系統有各種形狀和大小。明顯的共同點是；他們都使用事件來傳達信息。這些事件有多種形式和大小，確定事件中的內容會對系統設計產生巨大影響。

在這篇文章中，我想討論三種不同類型的事件。我希望澄清這些類型將使您能夠更好地討論事件驅動的架構和集成。

三種事件原型

當我與其他開發人員討論事件時，我區分了三種類型的事件。每種類型都有其獨特的特徵、優勢和劣勢。這些類型的事件都不一定比另一種更好，但在特定情況下，特定類型可能更適合。

這些類型的事件是：

1. 領域事件

2. 觸發或信號事件

3. RESTful 或 “胖” 事件

讓我們逐一介紹它們，看看它們是什麼，以及它們何時有用。

領域事件

對於任何對領域驅動設計感興趣的人來說，這將是最熟悉的事件類型。領域事件是歷史的記錄，捕捉重要時刻的意圖和任何相關上下文。領域事件關注 “領域”，這意味着它們關注與業務相關的事物。因爲他們記錄歷史，所以他們用過去時表達。

領域事件以明確表達意圖的方式命名。建議使用人類語言來命名這些事件，儘量避免使用 “嗶嗶” 語言。而不是命名事件 OrderStateChanged 或 OrderEvent，使用類似的東西 OrderWasShipped。

與其他事件類型不同，域事件非常適合捕獲意圖。因爲領域事件只捕捉重要時刻的相關上下文，所以它們也非常適合捕捉變化。這讓活動消費者對正在發生的事情有了深刻的瞭解。事件源系統更進一步，使領域事件成爲軟件模型的基石。

領域事件特別適合用於創建讀取模型。在讀取用例要求與有助於做出決策的數據模型非常不同的情況下。在創建讀取模型和分析數據模型中，以更改和意圖爲中心的表示非常適合聚合。

• 優點

領域事件非常適合捕捉意圖和 “變化”。它們允許您構建強大的讀取模型，其擴展性比原始數據模型上的複雜查詢要好得多。領域意圖對於創建分析模型非常強大，它可以提供對業務中正在發生的事情的深刻見解。

• 缺點

域事件暴露了域內部發生的事情。如果消費者依賴此信息，他們就會與之耦合。如果使用領域事件來創建決策模型，那麼這些事件的耦合會對開發速度造成壓力。耦合增加了改變的成本，所以知道你暴露了什麼以及暴露給誰總是好的。作爲默認做法，將每個域事件視爲 “私有”，僅用於內部使用。只有通過故意曝光，消費者才能訪問事件，類似於使用 API 而非直接訪問數據庫的方式。

觸發或信號事件

觸發或信號事件是最小的事件。此事件通常僅包含一個引用聚合或實體的 ID，也可能包含時間戳。正如名稱觸發器所暗示的，這些事件用於觸發消費方的反應。觸發器最常用於通知其他業務流程發生變化。在您存儲敏感數據的情況下（看看您，GDPR），使用觸發器可以幫助防止將事件基礎設施暴露於具有挑戰性的要求。

• 優點

當域事件可能包含敏感數據時，觸發器很有用。在這些情況下，生產者發出一個信號並期望消費者使用安全的 API 來獲取相應的 ID。觸發器不容易引起信息級耦合，僅僅是因爲它們不包含任何內容。

• 缺點

由於觸發器不包含任何信息，因此消費者總是依賴於 API。當許多消費者消費許多事件時，這可能會給您的系統帶來一些意想不到的負載。信息的缺失也限制了彙總數據的能力。

由於事件是異步處理的，因此從 API 檢索的數據可能處於消費者期望的不同狀態。消費者必須始終檢查從 API 檢索的資源是否是他們所期望的，並準備好處理資源可能處於的任何可能狀態。例如，如果訂單已發貨，但商家立即取消發貨，則消費者可能會檢索到與事件名稱所暗示的狀態不匹配的貨運資源。當發生事件處理延遲時，這可能會產生意想不到的結果。

RESTful 或 “胖” 事件

最後一個原型是 “胖” 事件。我個人更喜歡術語 RESTful 事件，因爲它更好地描述了有效負載中的內容。這種類型的事件包含您將從 RESTful API 檢索到的完整資源表示。這是一個很好的整合活動，對外部消費者最有用。

與觸發器相比，RESTful 事件阻止消費者往返 API。如果將其與域事件進行比較，它可以防止消費者不得不組合多個事件來獲得完整的畫面。

• 優點

RESTful 事件非常適合將狀態推送給消費者。在一個事件中，消費者對資源瞭如指掌。對於每個資源，只需將最後一個事件備份到最新狀態，這對於災難恢復非常有用。如果另一個服務依賴於您的服務的狀態，則使用 RESTful 事件是一種將狀態推送到那裏的好方法。在最終一致性可以接受的情況下，這樣做將消除對服務的直接依賴。

• 缺點

根據我的經驗，RESTful 事件僅作爲 “外部” 消費者的集成工具有用。它們對內部建模沒有用處。它們很大，更匿名，傳達的意圖較少，因此不太適合內部建模。RESTful 事件通常需要您構建一個防損壞層來將其他類型的事件轉換爲 RESTful 事件，這是 “額外” 的工作。

就事件進行有意義的討論

在技術討論中，很容易跳到解決方案上。只需添加該字段，只需將此內部事件公開給外部消費者，即可解決問題。我希望通過確定幾種類型的事件，您可以將這些信息帶入您正在進行的討論中。嘗試確定計劃中的事件類型，它們具有哪些特徵，以及這些特徵如何影響您應用它們的情況。暴露領域事件？注意信息級耦合。因爲消費者需要它們而將越來越多的信息添加到事件中？也許切換到 RESTful 事件。最後，請記住，如果在正確的環境中應用不同的溝通方式，效果最好。您應該意識到這一點並做出正確的選擇。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/CyeYK5fNgTHTvTjJfWZUuQ