隨著 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): 領域事件是領域專家對所有該領域有興趣的事件。一般來說，有三種事件發生的源頭，第一，商業流程的其中一個步驟，比如說，在電商中，顧客下訂單或是商品送達；第二，商業或系統流程中定時發生的事件，比如說，每月的銷售金額結算；第三，某領域事件導致另一個領域事件的發生，比如說，三次密碼輸入錯誤後，使用者帳戶被上鎖。
