1、引言

上次初步瞭解了什麼是領域事件和為什麼要使用領域事件的相關概念，接下來就要繼續深入，如何對領域事件建模，

2、事件建模

事件建模也被稱為事件風暴，形式有點類似於頭腦風暴的方法,通過事件風暴的方法可以快速分析複雜業務領域，完成領域建模的目標。

事件風暴是一項團隊活動，是在通過領域事件識別出聚合根，進而劃分微服務的限界上下文。在活動中，團隊先通過頭腦風暴的形式羅列出領域中所有的領域事件，整合之後形成最終的領域事件集合，然後對於每一個事件，標註出導致該事件的命令（Command），再然後為每個事件標註出命令發起方的角色，命令可以是使用者發起，也可以是第三方系統呼叫或者是定時器觸發等。最後對事件進行分類整理出聚合根以及限界上下文。

事件風暴建模是基於領域驅動設計DDD的業務建模方式，它能夠直接分析動態業務流程。動態的業務流程就是說在對於一個狀態要做什麼樣的措施。事件風暴就是開發人員們一起討論分析哪些狀態需要建模領域事件(必須是有價值的)，事件建模的原則是不修改原本程式碼，保證程式碼的高度解耦。所以事件建模可以理解為封裝，封裝的原則就是以不變應萬變，不變的是原本的業務，變的是對於業務執行後的狀態的處理，例如訂單從待付款變為已付款，這個業務本身不變，變的是將支付成功這個結果的應對方法。

建模事件需要知道事件的來源，有因必有果，建模事件必然是有原因和結果的，事件是由事件源和事件處理組合而成的。通過事件源我們來辨別事件的來源，事件處理來表示事件導致的下一步操作。

事件源應該至少包含事件發生的時間和觸發事件的物件。事件處理要與事件源進行繫結，所以我們再來定義一個泛型介面。

領域事件不是無緣無故產生的，它有一個釋出方。同理，它也要有一個訂閱方。

那如何和訂閱和釋出領域事件呢？ 領域事件的釋出可以使用釋出--訂閱模式來實現。而比較常見的實現方式就是事件匯流排。 事件匯流排是一種集中式事件處理機制，允許不同的元件之間進行彼此通訊而又不需要相互依賴，達到一種解耦的目的。

3、例子

假如有一個系統程式碼中存在大量的重複程式碼，過長函式，過大的類，過長的引數列表，註釋不清等問題。實際研發過程中也是經常出現一點改動都可能會引起不可預測的結果，重構勢在必行。

但是在重構過程中，沒有人可以說清楚現有系統的邏輯，如何重構呢？採用事件風暴的辦法，通過對領域中所發生的事情（也就是領域事件）來探索這個領域。

舉例來說，能夠引發事件的事情包括使用者行為（登入、修改密碼等）、外部系統所發生的事情（外部介面的回撥）以及時間的流逝（某個特定的時間點）。事件也有助於找到領域的邊界，對術語的不同闡述可能就意味著存在邊界。

準備工作，四色貼紙：

橙色：事件，某個動作的結果，以“XX已XX”的方式表示，比如“使用者資訊已查詢”

藍色：屬性，事件相關的輸入、輸出資料等

黃色：命令，某個動作，比如“查詢使用者資訊”

綠色：實體，命令的觸發者

開始梳理業務，將結果貼到白版上

繼續深入梳理，將整個過程的模型、關鍵資料等梳理出來，貼在白板上 確定重構指導思路，執行重構動作，重構的同時引入單元測試保障重構的質量。

（以上例子原貼：https://www.jianshu.com/p/acb7c8026c21 ）

4、小結

領域事件建模需要做到兩點：

• 多人一起討論商量對業務是否值得建模，分析業務需求，梳理過程。

• 建立領域事件模型（可以以釋出訂閱訂閱模式建立）

對於需要處理的事件，呼叫事件處理介面，做出相應的處理。

領域事件本質上是對程式碼的封裝，原業務不做任何改動，只調用事件處理介面，以達到解耦的目的，理解了事件建模，需要做到的就是建立領域事件模型來統一