Event Storming

隨著軟體服務越來越複雜，很多時候團隊的領域知識(Domain-Know How)是很難共享的。尤其在團隊之中會遇到特定的邏輯只有少部人知道關鍵邏輯。其他人在合作上會遇到認知上的落差，導致團隊合作上溝通麻煩及代溝。

例如:之前在工作上對於訂單產品相關知識，兩個人有兩個說法，三個人有三個人說法。這導致了開發上邏輯非常混亂，這時候我提出跑一次 Event Storming工作仿。用來釐清需求及各種專有名詞。並讓參與人員一起討論關於產品訂單的流程概念。目的是為了釐清需求和專有名詞，並讓所有參與者共同討論產品訂單的流程概念。

事前準備

需要一份畫紙捲及很多顏色的便利貼，找一間有很大的牆面或是會議室。至於便利貼，最少要有以下有基本顏色較佳。

Event Stroming Cards

卡片顏色及介紹

Domain Event 領域事件

橘色便利貼 : 表示領域事件，指在業務流程裡面產生的事件(使用英文表示應用過去式)。例如:所在地座標已重新定位(領域事件)。

User/Actor 使用者或是角色

黃色便利貼 : 表示使用者或是角色。例如:系統管理員。或是像是職位等等均可以表示。

Business Process 邏輯處理

紫色便利貼 : 表示商業邏輯或是領域事件發生之後，需要如何處理。例如:當物件上架，則寄Emal會通知會員。

Command 命令或是使用案例

藍色便利貼 : 表示使用者決策執行動作，也表示使用者意圖，同時也會產生領域事件。例如:進入聊天室，本身具有命令及決策意圖。

External System 外部系統

粉紅色便利貼 : 外部系統，可以是外部服務或是任何資料儲存方案。例如:任何資料庫方案或是第三方服務等等。

Aggregate 聚合根

深黃色便利貼 : 聚合根，這是也是領域驅動設計強調的概念，表示一群領域物件的集合，可以視為一個單元。這往往是最後軟體設計結果。這設計包含對於領域邊界劃分。

View/Read Model 讀取模型

綠色便利貼 : 使用者介面或是可以標記UI最重要的欄位，亦可以截圖補充說明。例如:任何使用者介面。

Question 任何問題

紅色便利貼 : 任何參加者對於任何流程有問題，均可以貼，方便後面進行討論。

Big Picture

Event Storming Big Picture Domain Events

一開始是請所有的人員進行對於這問題用戶可能會有那些任務需要被完成的。例如:登入、建立產品資訊…等任務。將這些領域事件找出來並以橘色卡片寫領域事件。如果有問題可以先貼紅色便利貼把問題寫下來，等大家一起討論。
也可以找出所有淺在的使用者以黃色便利貼表示，並決定使用者是否能觸發事件。這邊也是授權使用者那些功能。

可以藉由找一段流程說明使用者如何操作系統，依照內容大家依序寫出領域事件。

以下是整理當初跑Event Storming需要注意的:

1. 時間軸由左至右

發生的領域事件一定有先後順序的，需要由最早發生的事件由左排至右邊。

2. 事件是會改變系統狀態

領域事件是會改變系統狀態，所有查詢動作可以暫時忽略。藉由需求進行分析淺在領域事件。

3. 領域事件並不是CRUD

由於團隊還是以資料庫為核心去思考，導致在寫領域事件這件事會出現了UpdateXXX，領域事件而是AdvertiseRenameEvent…等，用來敘述在這個系統領域中使用者發生事情，也表示了使用者想要做什麼事情。

4. 領域事件用英文過去式

使用動詞過去式（英文加 -ed ，中文加「已」)，舉例來說:訂單已成立、貨物已送出…等等。

Process Modelling

在確定了用戶和事件後，可以在用戶與事件之間加上命令或使用案例，用藍色便利貼表示，並標示事件之間的相互關聯和後續處理，使用紫色便利貼。

這時候已經有了User、Domain Event。我們可以在User與DomainEvent之間加上命令/使用案例以藍色便利貼表示。以及事件與事件有沒有連動關係。舉例來說:訂單已成立了，可能會與通知系統連動。這時候可以使用紫色便利貼貼在訂單已成立後面，表示針對這事件，我們需要去做後續的處理。

1. 命令一律以動詞開頭

命令用動詞開頭。舉例來說 : CreateUserCommand。

找出所有事件之間關聯中間使用紫色卡片貼上表示處理事件處理者，可能去執行其他的使用案例。

Software Design

這邊會進行 Aggregate 的設計，這時候也會對於所有使用情境有所瞭解。

這時候需要將所有使用情境列出來，驗證領域模型是不是能夠符合所有的情境。但這部分就留到下一篇文章進行介紹。

總結

個人已在團隊中使用Event Storming進行專案需求及分析，對於在專案溝通上也有很大的幫助。例如: 程式碼命名這件事，大家容易在這時候同步相同的英文詞彙及概念，減少後續維運上的困擾。

還有對於整個系統流程梳理上更容易知道系統的整體流程與流程流向。對於軟體服務上的設計提供比較明確的方向，也比較容易找出服務之間邊界。

目前有做過Event Storming的專案，對於整個系統有比較深刻的印象，尤其是邏輯及功能這樣對於個人對於系統的 Domain-Know How 有更深的了解。也是歸功於Event Storming的分析與視覺化。個人感想是Event Storming是Domain Driven Design價值很高的一種方式。