『科技雷達』技術篇：Event Storming
隨著 Distributed Systems 和 Microservices 在業界逐漸成為主流的架構，以 Event 為主的系統架構越來越受到重視。如何來做此類系統架構的設計也變成近來科技產業所專注的領域。Domain Driven Design便是目前主流的架構設計方法論之一。而在Domain Driven Design 中的需求釐清和對領域的共識上，Event Storming 也成為了產業中主流的工具之ㄧ。
前言
知名的軟體開發顧問公司 Thoughtworks 定期會對科技的各種技術做分析，也發佈其內部對該技術的採用和看法。此系列文的是對其所討論的技術來做一些延伸的整理，研究和分享。有興趣的可以去 subscribe 他們的 Newsletter。
什麼是 Event Storming 和為什麼你需要 Event Storming？
Event Storming 是一種 Workshop ，其目的是讓你的團隊快速地了解在商業領域 ( business domain ) 中所發生的事件 (Event)。由於它的本質是利用一個有系統的方式去讓不同的看法經由 Event Storming workshop 分享出來並進行深入的討論。由於並不是以技術為主，所以其實可以被應用在不只是系統設計，也可用於策略思考和流程設計等。
跟傳統的需求釐清不同的事，這個方法論注重於參加者之間的對話以達到對該題目的共識，而不是像比如說用 UML 或是 BPMN 去產生很多的不同的系統或流程圖，當然在 Workshop 之後，你也可以用這些工具去紀錄對話和討論的結果，但這並不是 Event Storming 的目的。另外一個值得注意的是，Event Storming 的重點放在時間的演進和各個事件 (Event)在時間軸上的相對應關係，這和一般來說我們所做的注重於資料和系統互動的系統設計也有很大的不同。Event Storming workshop 有兩個重要的元素：
- 領域專家(Domain Expert): 領域專家通常不對技術有了解，他們不知道各種不同資料庫的差別，也不知道系統架構設計的模式，他們是對商業模式和運作的專家，知道有哪些事情需要發生才能讓這個公司順利運作。
- 領域事件(Domain Event): 領域事件是領域專家對所有該領域有興趣的事件。一般來說，有三種事件發生的源頭，第一，商業流程的其中一個步驟，比如說，在電商中，顧客下訂單或是商品送達；第二，商業或系統流程中定時發生的事件，比如說，每月的銷售金額結算；第三，某領域事件導致另一個領域事件的發生，比如說，三次密碼輸入錯誤後，使用者帳戶被上鎖。
如何進行 Event Storming Workshop？
如同前面所說，與領域專家們的對話和討論是 Event Storming Workshop 的核心，在進行時需要特別注意下列這些事項：
- 在開始時，首先注重在團體的了解和學習，在主持時，持續用開放性的問題來讓參與者做進一步的討論。一些範例問題如下：
“What circumstances would cause … to happen?”
“What was the path that led us here?”
“What is a good example of …?”
“What do you mean by …?
“What might lead someone to do/need …?”
“What else might happen…?
- 用具體的商業實例和流程而不是用抽象概念來進行討論
- 設定 Timebox，訂定時限以聚焦討論主題，並鼓勵參與者將問題或假設寫下後供之後討論
- 釐清模糊的領域概念和事件，但不需要急於統一用詞，在過程中引導參與者對其概念或事件產生共識和共用詞彙與語言(ubiquitous languages)
Event Storming Workshop 的步驟
第一步：解釋 event storming workshop 的流程和目標
所需時間：30 分鐘
使用下面 Event Storming 的說明和關係圖來解釋workshop的目標和所會用到的各種不同的概念。最有效的方式，通常會是利用這些說明和關係圖去做一個簡單的案例，比如說，TODO list app或是購物車。這部分的說明大概會需要三十分鐘。
第二步：領域事件的探索 (Domain Event Discovery)
所需時間：30 分鐘
所需準備事項：準備足夠的空間(實體的或是虛擬的)，已讓參與者可以自由地在時間軸(下圖中的 Modeling Space ，左側為時間的起始點)上做調整。並將第一步中的說明和流程圖擺在所有參與者都可以輕易的回去參考的地方。
進行方式：將參與者分成二到三人的小組，每個小組最好至少有一名領域專家，讓各小組各自的將領域事件在時間軸上根據事件發生的先後次序由左到右的排列，在此階段，會注重在 Domain Events (橘色便利貼)，和問題與假設(粉紅色便利貼)。領域事件之前有做過說明，這邊就不多做討論；問題與假設的部分是讓各小組能夠在大方向上做討論而不是去討論細節，比如說，“商品訂價策略的未定”，“沒有人知道詳細的系統結帳邏輯”。
在過程中，鼓勵參與者將自己小組內所討論的領域事件連結到其他小組發想出的領域事件，並將時間軸持續的去根據新加上的領域事件去調整。如果不同小組用不同的詞彙去討論了相同的領域事件，可以用一個替代的詞彙去取代它，或是加一個問題在這領域事件上，以供之後的討論。
第三步：看時間軸講故事
所需時間：20 分鐘
這個步驟最主要的目的是整理時間軸，並讓所有參與者有機會了解全局，對整個商業流程有足夠的了解，以增加接下來的討論的效率和效用。
根據時間軸，讓參與者從時間軸開始到結束，再從結束回到開始一一的回顧每個領域事件，在過程中，加入額外的領域事件將補齊時間軸。另外一個重要的事項是在敘述時間軸時，找出重要的領域事件(Pivot Event)，根據該事件去對整個時間軸去做切割 (可以用膠帶將Pivot Event隔開，將時間軸根據Pivot Event去分成多個區段)。
第四步：找出決定點(Decision)和指令(Command)
所需時間：30 分鐘~
在將所有的領域事件根據時間軸列出來後，接下來便是找出 Actor 和Decision / Command。Actor 可以是系統或是使用者，Actor 或根據系統產生或是外界資訊去做出決定或是發出指令，這個決定或是指令則會觸發領域事件。
各個小組可以根據前一個步驟根據Pivot Event產生的區段，去各自對其區段去討論和發想出 Actors 和 Commands。十五分鐘後，各小組交換負責的區段，去補齊和了解前個小組的想法。如果有多個區段的話，最好可以規劃讓各個小組有機會去確認各個區段的Actors，Command和Domain Events。
第五步：找出商業分針和流程(Policy)
所需時間：20 分鐘
這個步驟的最主要目的是找出在 Commands 和 Domain Events 間，有沒有一些固定的規律和規則。在主持時，可以持續的問參與者，“這個指令和領域事件的關係是不是總是會發生？”，或是，“發生某事件後，是不是這個指令總是會被引發？”
Policy could be implicit through convention or unspoken rules, explicit via formal processes and business rules or through automation by system rules.
第六步：找出和命名 Aggregate
所需時間：30 分鐘
Aggregate 是系統中記錄狀態的資料集合。Aggregate 接收指令並處理及改變其狀態後，接著產生領域事件。將這一步驟留到最後是非常重要的，第一，到這個步驟時，時間軸，領域事件和這些事件是怎麼被觸發的應該都已非常清楚，去定義 Aggregate 會相對容易許多；第二，若是一開始就去定義 Aggregate，很容易會陷入現有系統的框架中。
此處的 Aggregate 通常是 Events 和 Commands 的集合。而在這邊所定義的 Aggregate 通常就會變成 Mircoservices 的服務界線 (Service Boundary) 或在 Domain Driven Design 中，加上資料架構後，變成 Bounded Context 。
結語
“It is not the domain expert’s knowledge that goes into production, it is the developer’s assumption of that knowledge that goes into production”. — Alberto Brandolini
不管你花了多少時間和使用者或是Stakeholders 去了解使用案例，花了多少時間去寫每一個 Story，最後產品化時，是根據工程師對使用案例的了解和假設的實作。我想這也是近年來 Domain Driven Design 變得越來越重要的緣故，領域專家和開發團隊的在定義問題和瞭解商業流程和問題的協作變成軟體產品開發的核心，也讓團隊的產出更加地具有商業價值。
P.S.: 案例和流程圖我是用 Lucidchart 做的，跟遠端團隊做 Event Storming Workshop 時，Lucidchart 也提供了不錯的即時協作功能。若你有興趣做遠端的 Event Storming Workshop，並需要 Lucidchart的檔案，歡迎在 Linkedin 聯繫我。www.linkedin.com/in/chienkuo
Domain Driven Design 系列文：
[Domain Driven Design] 簡介和為什麼你需要DDD
[Domain Driven Design] 第一步：了解價值鏈與定義領域模型
[Domain Driven Design] 第二步：Bounded Contexts 和其應用
[Domain Driven Design] 第三步：建立 Context Map
科技雷達系列文：
『科技雷達』技術篇：Evolutionary Architecture
