透過本篇文章您可以瞭解到以下內容：
- Event Storming的由來
- Event Storming具體實施流程
- Event Storming的一個簡單示例
- 總結
Event Storming的由來
當我們在談到Event Storming（事件風暴）時，通常會需要談起兩個概念：DDD（Domain -Driven Design，領域驅動設計）以及微服務。
那麼這三者到底有什麼關聯呢？
無論是Event Storming 還是DDD或者微服務，三者都是為了解決同一個問題，那就是軟體系統設計遇到的困難。
微服務作為一種架構設計，透過將單體應用拆分成若干個微服務，從而把原來內部的耦合性、複雜性進行最大程度的降低，變成可控制化，進而更好的應對業務的快速變化。
DDD是一種軟體系統設計和開發的方法論，是一種指導思想，它從理論層面告訴我們如何進行架構的設計。
到這裡我們有了目標，微服務架構; 我們也有了指導思想，就是DDD ; 可是我們具體落地的方案是什麼呢？ 亦或者說我們實現微服務拆分具體可實施的路徑是什麼呢？
此時Event Storming登場了，並且給出了完美的答案。
它是將DDD落地到了具體的實踐層面，透過workshop形式，將對應的技術人員以及領域專家集中在一起，透過可視化便條紙的方式，以及高互動的交流從而一步一步的挖掘和梳理出業務流程， 並形成業務邊界和初步的微服務劃分，最終形成統一的業務語言。
此外關於Event Storming，我們不得不提到一位大師，他就是Alberto Brandolini，Event Storming 就是他發明創造的。
關於Event Storming的定義如下圖所示：
Event Storming是一種靈活的研討會形式，用於複雜業務領域的協作探索。
它可以按照不同的形式進行展開，適用於以下多種場景。
- 評估現有業務運行的狀況，並發現最有效的提升業務情況的措施
- 探索新業務模式的可行性
- 設想新的服務，最大限度為各個參與方帶來積極正向的成果
- 幫助設計整潔並且可維護的事件驅動軟體，以便於支撐快速發展的業務
Event Storming 具體實施流程
在正式開始進行Event Storming之前，我們需要進行一些準備，這裡我把它歸結為三大類，如下圖所示：
需要準備的物理條件大體分為四大類，如下圖所示：
- 會議室（較大的開放空間），用於技術人員、領域專家等成員之間的充分討論。
- 便條紙（各種顏色，用於代表不同意義，例如Domain Event、Command等）。
- 筆 （最好每個人一支），用於在便條紙上書寫。
- 白板 用於貼便條紙。
在物理條件具備以後，接下來就是需要邀請相關人員進行參與，整體可以分為三類人員：
- 召集人，熟悉整個Event Storming的流程，保證整個過程大家順利完成。
- 領域專家，對業務流程精通的人，在整個Event Storming過程中負責澄清業務上的某些概念，並且查看是否有遺漏的事件。
- 項目成員，該專案的成員，角色包括開發人員、架構師，透過Event Storming快速讓整個團隊熟悉瞭解整個專案的業務流程。
在物理條件準備以及人員邀請完成後，我們還需要對參與此次專案的人員進行關於Event Storming的概念和組織方式的介紹。 因為在整個Event Storming過程中會使用到不同顏色的便條紙，不同顏色代表的內容含義不同。 由於參與整個workshop的成員不一定很熟悉具體含義，此時可以由召集人進行具體的介紹和解釋，每種不同顏色的便條紙怎麼去使用，如下圖所示：
域事件
一般情況使用橘色便條紙表示，代表業務流程中已經發生的事件，此處需要注意的是需要用過去式表示。 例如用戶已註冊（User Registered）。
命令
一般情況使用藍色便條紙表示，代表產生某一事件的動作。 即在之前產生的領域事件中加入Command的概念。 其中Command代表的是意圖、動作。
視圖
一般情況使用綠色便條紙表示，代表使用者與之交互以在系統中執行任務的視圖。
政策
一般情況使用紫色便條紙表示，代表某種規則。 例如在支付過程中，需要輸入密碼，而多次輸入錯誤，就會觸發賬戶凍結操作。 多次輸入錯誤，就是我們的Policy，而賬戶凍結就是被Policy觸發的新的領域事件。
演員
一般情況使用黃色便條紙表示，代表一類特定的使用者。
骨料
一般方式使用尺寸比較大的黃色便條紙表示，代表概念相同的command和domain event聚合在一起。 可以認為Aggregate就是微服務的雛形。
外部系統
一般情況使用粉色便條紙表示，這個相對好理解，代表的是第三方外部系統。
故障點
一般情況使用紅色便條紙表示，遇到的麻煩，或者問題。
至此前期準備都已經完成，接下來讓我們看下整個流程是怎樣的。
首先是領域事件的收集。
這些事件是要以過去式的方式進行表達，是因為從通俗語言的角度來理解，事件本質上就是已發生的事實。
這裡需要注意的一點是事件是有相對順序的，我們可以把有相對順序關係的事件放在同一行並貼在之前準備好的白板上。 此外由於每一個人都可以進行事件的書寫，此處不必擔心彼此書寫重複，後續可以進行合併，缺失可以由領域專家進行指正，補充。
另外一點，由於參與人員有時並不一定十分熟悉整個流程，可以由召集人書寫第一個事件。
在收集完所有領域事件之後，我們可以在此基礎上進一步探索，並加入Command以及Actor角色。 即某個Actor執行了某個Command產生了對應的Domain event。
此時在融入Domain event、Command、Actor后，可能會產生更多思考，例如某些command是否在特定的條件下所觸發，而這種邏輯就是Policy 。
接下來我們將相同Command以及Domain event進行歸類，代表的就是Aggregate，此時我們用尺寸比較大的黃色便條紙進行表示。
最後透過Aggregate我們就可以相對容易的劃分子域和界限上下文了。
Event Storming的一個簡單示例
透過上一章節的介紹，相信大家對Event Storming中的概念，以及實施流程有了較為清晰的理解。 可能有些概念較為晦澀抽象，同時Event Storming本身是以workshop動手實踐為主的形式， 所以為了更好的加深我們對整個流程的理解和認知，接下來會結合一個例子，再次來回顧下整個流程。
我們以一個一般用戶註冊的業務進行說明：
第一步：定義Event
我們需要尋找Domain event，在上面描述的場景中，用戶註冊就是一個典型的Event，需要注意的是我們需要使用過去式的方式，所以對應的這個Event就是“用戶已註冊”。
第二步：尋找Event對應的Command
Command是代表某一個事件對應的動作，在上一步驟中描述的Event“用戶已註冊”，我們可以確定相對應的 Command是“註冊使用者” 。
第三步：定義Actor
Command是由誰發起執行的呢？ 如果我們接受任何用戶進行註冊申請，那麼在這個Event Storming的流程里，一般使用者就是Actor。 即一個用戶通過註冊使用者的這種動作，產生了一個與之對應的用戶已註冊的事件。
第四步，定義Policy
在第一到第三步的過程中，可能會遇到某些邏輯下才觸發的Command，比如用戶註冊成功以後，系統推送簡訊或者郵件提醒。 這種邏輯稱之為前面介紹過的Policy。
以上的第一步到第四步我們可以進行重複進行，直至整個業務流程都梳理完畢。 然後將command和domain event歸類聚合在一起，就形成了如下的Aggregate，微服務的雛形就初步形成了。
這是一個非常簡單的示例以介紹Event、Command、Actor等的概念和大致Event Storming 的流程，但是在實際工作過程中，往往業務場景會非常複雜，企業級應用涉及到的事件會很多，我們需要針對每個事件進行相關聯的分析和梳理以支撐後續的微服務設計的進一步細化。
總結
要實現微服務架構設計，我們可以使用DDD作為思想指導，並使用Event Storming進行具體實踐落地。 在本篇文章中依次向大家介紹了Event Storming的由來、定義、前期準備要求，以及整個Event Storming實踐流程。
Event Storming之後，我們就需要結合Event Storming的產出，即微服務的雛形，進行下一步操作— Boris。 什麼是Boris，整個實施的流程又是怎樣的？ 我在下期的文章中會繼續和大家進行交流分享，敬請期待！
參考連結：
https://tanzu.vmware.com/developer/practices/event-storming/
作者簡介
Comments
0 Comments have been added so far