事件風暴

本文譯自事件風暴提出編寫檔案：http://ziobrando.blogspot.com/2013/11/introducing-event-storming.html

免責聲明：這是關于 EventStorming 的開創性文章。這是一切開始的地方，是以我認為保留原件是相關的。同時， 自從我寫這篇文章以來，EventStorming 已經發展了很多，這個頁面描述的格式不再是我最喜歡的。事實上，沒有單一的 EventStorming 格式，該工具證明了自己的多功能性和強大功能，以至于我完善了一些不同的方法。我還不得不開始 寫一本關于它的書，它正在慢慢地完成。到今天為止，了解 EventStorming 潛力的更好切入點可能是我稍後的示範文稿50.000 個橙色便簽（也可以在視訊中找到）) 或閱讀本書的第一章，這是免費的。我們還在開發EventStorming.com網站的新版本，該網站應該組織指向許多從業者釋出的有關 EventStorming 的有趣内容的指針。

在過去的幾個月裡，我花了一些時間來試驗這個奇怪的東西。一開始就像“哎喲我沒時間畫精确的 UML 圖，讓我們來做這個吧”然後變成了我在 2012 年意大利靈活日上提出的基于事件的模組化研讨會，後來我有機會做更多的實驗在 Vaughn Vernon 的 IDDD 之旅期間在比利時和波蘭，我收集了非常寶貴的回報和見解。我設法找到了一個更酷的名字 - EventStorming - 就在 2013 年夏天整個事情爆發之前。雖然我意識到它有很多價值，但其他從業者（Mathias Verraes、Tom Janssen、Marco Heimeshoff、Yves Reynhout、Tomas Jaskula，Alessandro Colla、Andrea Balducci、Jef Claes，僅舉幾例）開始探索和使用這種格式并取得了驚人的結果，這讓我得出結論，這不僅僅是“另一種研讨會格式”。

什麼是事件風暴

EventStorming 是一種研讨會形式，用于快速探索複雜的業務領域。

它很強大：它使我和許多從業者能夠在數小時而不是數周内提出完整業務流程的綜合模型。

它很吸引人：整個想法是将提出問題的人和知道答案的人帶到同一個房間，并一起構模組化型。

它是高效的：生成的模型與領域驅動設計實作風格（特别适合事件溯源方法）完全一緻，并允許快速确定上下文和聚合邊界。

這很容易: 符号非常簡單。沒有複雜的 UML 可能會使參與者遠離讨論的核心。

很有趣：我一直很開心上司研讨會，人們充滿活力，傳遞的成果超出了他們的預期。正确的問題出現了，氣氛也是正确的。

它是如何工作的

以下是基本步驟：

• 邀請合适的人 參加研讨會。理想情況下，您需要一個可容納 6..8 人的大型會議室，由知道要問的問題（并且好奇地想聽答案）的人和知道答案的人組成。
• 提供無限的造型空間。複雜的問題往往沒有得到正确分析，因為沒有足夠的可用空間來檢視 問題。你的問題比你的白闆還大，那又怎樣？我的解決方案是 使用任何可用的工具（我最喜歡的工具是宜家紙卷）來破解模組化空間，以擺脫空間限制。
• 從領域事件開始探索領域。一個域事件是有意義的事在發生域。它可以很容易地翻譯成軟體，但這裡的真正價值在于它可以從非技術人員那裡快速掌握。一個事件可能是另一個事件的追随者的前身。根據時間線将它們全部放置在您的模組化表面上（慣例是為此目的使用橙色便簽）。
• 探索領域事件的起源。某些事件是使用者操作的直接結果 —> 使用藍色 便簽将其表示為指令。其他是外部系統中發生的事情或時間流逝的結果，我們将為它們使用紫色 便簽。在其他一些情況下，我們會有一些其他事件的直接結果的事件。我們将簡單地将這兩個事件放在一起。
• 尋找聚合。我們不是從代碼開始定義聚合，而是采用由外向内的方法：聚合是系統的一部分，它接收指令并決定是否執行它們，進而産生域事件。

獎金目标

這些是原始 EventStorming 格式的基本步驟。但是，如果讨論變得熱烈，您可能會在此過程中發現一些獎勵目标。這是一個可能的獎勵目标清單，值得考慮作為标準路線的有益繞道。

• 探索子域：一些領域專家會在某個領域展示更多的專業知識，而将領域的其他部分留給其他人。如果您過去看過我的演講，不同的責任領域可以很好地映射到不同的子域或豬肉部分。
• 探索有界上下文：在讨論過程中，可能會出現一些沖突區域。具有 DDD 思維方式的開發人員和協調員會發現對術語的不同解釋，作為圍繞含義進行讨論的觸發因素。這可能是在您的域中共存的多個一緻模型之間劃清界限的好時機。
• 繪制使用者角色：在談論指令時，對話往往會轉向發出指令的上下文和觸發操作的人的目标。這是有價值的資訊，不要吹！您可以擴充符号以包含小的黃色便箋作為角色。
• 草圖關鍵驗收測試：如果讨論開始圍繞極端案例或模棱兩可的場景展開，沒有比定義清晰的驗收測試更好的方法來消除歧義。并非所有場景都需要以這種方式記錄（我的意思是不在本次研讨會中，主要是出于時間原因）但如果它們在某些領域是決勝局，那麼現在沒有理由不捕捉新興知識。
• Sketching Key Read Model Artefacts：對于某些場景，使用者所看到的遠比系統所做的重要得多。如果螢幕、表格或圖形對給定使用者特别有價值，隻需将其草繪在便箋中并将其放置在與其關聯的指令附近。

以下是迄今為止所有可能的研讨會步驟的概述：

可以在這裡看到品質更好的圖像

把所有東西放在一起是很多東西。請記住，研讨會的目标是在盡可能短的時間内盡可能多地學習。我們邀請了關鍵人物參加研讨會，我們不想浪費他們的時間。

是以，當談到這些獎勵目标時，準備好以最有效的方式利用時間：你得到一個有價值的提示，隻需勾勒它并将相應的粘性放在熱點中。不要推動模型完整性的讨論：模型将是巨大的，完成它可能沒有什麼價值，甚至對某些參與者來說聽起來很可怕。

接受不完整會讓研讨會不那麼無聊，而且更有成果。

選擇正确的格式

正如您所注意到的，研讨會沒有單一的形式。事實上，第一步或多或少是相同的，但形式可能會根據參與者的角色和項目範圍而有所不同。

最小範圍

我發現即使在停止領域事件時，結果也非常有價值，即我們在我的公司進行了一個 EventStorming 會議，探索我們正在運作的教育訓練課程的業務流程。參與者不是開發人員，是以目标隻是通過提出正确的問題來了解系統。我們在幾個小時内就完成了。在研讨會結束時，每個新員工都清楚地知道我們公司應該做什麼。

（在這個場景中，我們使用了稍微不同的符号，這對參與者更有意義：橙色 —> 事件，紫色 —> 外部系統，藍色 —> 外部組織或社群，綠色 —> 人工制品）。 

在探索軟體開發時，結果更加強大。聚合、指令和領域事件，都很好地映射到軟體工件中。您可能會舉辦研讨會以真正快速地掌握全局，并提供一個實體空間，可以圍繞流程進行讨論。

将模型轉化為代碼

DDD 從業者喜歡這種方法，不僅因為它很有趣，而且因為生成的模型更接近他們需要的模型：這不是沒有資料模型。生成的模型是完全行為的：沒有底層資料模型限制實作的本質。如果您面向指令-查詢職責分離，那麼在嘗試研讨會之後，您可能會遇到為我提供啤酒的緊迫性。

您還可以幾乎立即開始編碼，并在很短的時間内驗證您在代碼中的探索結果。這是最高效的團隊所做的，基于讨論的發現與面向領域驅動的實作相結合可以帶來巨大的改進。

您基本上會更快地實施正确的事情。

我如何開始做 EVENTSTORMING？

運作一個實驗并沒有那麼困難。所有你需要的是：

• 一個合适的房間，安靜且足夠大以容納模組化表面（如果天氣允許，也可以選擇戶外模組化，但風可能是主要障礙）；
• 一個可寫的表面，很可能是宜家紙卷（代号 Måla，您可以在兒童區找到它）。
• 大量不同口味的便簽（基本套裝是淡黃色長方形便簽，外加橙色、藍色和紫色方形便簽）；
• 工作标記，理想情況下每個參與者一個加上備份；
• 一些美紋紙膠帶，以防萬一；
• 合适的人。
• 一個促進者。

在讓你的達斯維達式老闆參與進來之前，你可能想在沙箱中對執行進行原型設計（一些使用者組非常适合，他們喜歡實驗）。您可能還想加入不斷壯大的從業者和實驗者社群。

或者，您可能想聘請一名協調員，為期一兩天，在您的公司舉辦研讨會，同時提供有關研讨會本身和進一步可能步驟的指導。