EventStorming是一種非常流行的技術，它使我們比傳統技術更有效地探索，分析和建模業務領域。由此我們可以建立與設計更好的軟體系統和問題解決方案。

明智地使用EventStorming，我們可以發現有關我們的域和業務的足夠資訊，以便我們可以使用它來設計微服務，有界上下文甚至我們的團隊組織。

在公共培訓課程中和為客戶私下舉辦過許多EventStorming會議之後，我們注意到，可以將EventStorming應用於次優狀態，從而使人們質疑其價值，並使他們感到浪費時間。

另一方面，有效地應用EventStorming時，我們已經看到了許多成功的會議，其中許多團隊已將EventStorming用作其微服務設計的基礎。

在本文中，我們將分享一些易於學習的技術，這些技術將幫助您充分利用EventStorming的功能，從而可以設計更多與領域保持一致的軟體系統。

1.避免過早抽象

EventStorming開始時可能會採取的錯誤做法之一是建模過高。在許多EventStorming會話中，通過在更深層次上對域進行建模，可以釋放出殺手級領域的見解。在這裡，您可以打破幻想，檢驗假設並瞭解您的領域的實際運作方式。這使您能夠從單純的軟體模型擴充套件到真正的域驅動設計。

以線上職位公告板為例：

招聘人員登入系統、建立了招聘要求、釋出招聘、求職者申請職位、面試安排。

域就是這樣工作的，它是如此簡單，也是很膚淺的抽象，對我們沒有任何幫助。這個建模事件太普通了，太通用了，是一種抽象了的通用流程，並不是具體化。

2.從特定方案開始

為避免過早抽象，請從建模單個粒度流開始。例如，特定型別的使用者在特定時間以特定價格購買特定產品。

對單個流建模之後，在流中查詢子分支，然後分解為相鄰的流。

在上面職位釋出領域案例中，我們可以從外部招聘者註冊釋出職位開始建模。針對購買大型招聘計劃的外部招聘人員，然後針對購買輕型招聘計劃的外部招聘人員。

我們需要根據要招聘的業務來組織招聘廣告。而且，招聘政策有一個意見：如果您要招募多家公司來你這裡招聘，則必須採用不同的招聘模式，這會影響您的計費方式以及收到的報告的型別。

特定的招聘流程是這樣的：

外部招聘人員登入系統、分別購買大型招聘計劃和輕型招聘計劃、根據大型和輕量招聘策略將相應要求發給招聘者、招聘人員挑選一些。

外部招聘人員要遵守不同的招聘計劃，需要特殊的工具來組織其工作，需要不同的報告型別，在進行這樣更細化的建模時，您將開始看到流程分支，輸入，輸出以及各種方式的處理模式。

發現領域中極為重要的線索：自然所有和共同變化的部件，這些部件看起來相同，但關係鬆散得多。這是資訊的型別，是架構域驅動軟體系統的關鍵。

3.捕捉隱藏的意圖

我們看到許多初學者在將Form Submitted表單提交事件新增到他們的EventStorm時犯了錯誤。這不是領域事件，而是領域事件的技術實現。重要的是為什麼要提交表單：使用者的意圖是什麼？

除了使用Form Submitted之外，您還可以新增更多以域為中心的名稱，例如Job Post。

不要寫的技術事件：表單提交、按鈕點按、資料庫儲存；

業務事件的領域術語：廣告發布；工作陳列；支付接受。

後者才是領域術語，但仍然不夠。在為您的域中的資料提交建模時，可以使用以下技術來獲取更深入的域見解：

1. 列出每個單獨的資料（即表單上的每個欄位）
2. 列舉每個資料的可能值
3. 瞭解不同值的意義
4. 將重大差異建模為單獨的流程

可以通過一個示例更好地證明這一點：釋出工作時，表單提交中包含以下欄位：就業型別。它可以是永久或合同。該選擇具有很高的領域意義，導致業務流程發生變化，從而影響業務成果。

因此，在這種情況下，可能有兩個事件更好：永久職位釋出，合同職位釋出。然後為每個流程建模-尋找流程中的差異並尋找相似之處。您將獲得大量有關設計系統（尤其是設計微服務邊界）的最佳方法的見解。

4.懷疑警惕CRUD命名

具有通用字尾（例如Created，Updated，Changed，Changed或Deleted）的事件表示您正在使用技術術語來描述您的域而不是真實的域術語。

更新Updated可能是最大的警告訊號。更新是一個非常籠統的術語，基本上意味著已更改。當我們使用EventStorming時，我們試圖捕獲我們領域的豐富性，因此我們應該問“為什麼更新了某些內容？”。

對CRUD命名的懷疑不僅會幫助您開發更豐富的領域詞彙表，從而改善技術從業者與領域專家之間的協作，而且還將幫助您發現域內的其他流程。瞭解更改的每個不同原因，您將發現許多領域的見解。

例如取代”價格更改“，你可能會發現“價格折扣”，“最終季售價"，"聖誕促銷價啟用"或別的東西。

5.尋找狀態機和關鍵事件

狀態機幾乎遍佈每個領域。我們正在建模的概念經歷了不同的生命週期階段，即它們的狀態。

如果您特別注重查詢狀態機，那麼在發現域中的邊界（將成為微服務的邊界）方面會獲得更大的成功。

有一種特殊的事件可以識別狀態機狀態之間的轉換，稱為“關鍵事件”。關鍵事件是域邊界的有力指標。

在物聯網裝置領域，我們可能會發生以下關鍵事件：裝置製造，已配置裝置，已安裝裝置和已啟用裝置。儘管在整個過程中發生了數以百計的事件（例如，將裝置從倉庫中移出並安裝在公共場所），但這幾種關鍵事件是指示重大變化的關鍵業務事件。

6.到處問“如果？”

很容易陷入僅對域中常見路徑或快樂路徑場景建模的陷阱。但是，通過探索所有邊緣情況，還有很多東西要學習。

要梳理您域中的邊緣情況，請檢視牆上的每個事件並詢問“什麼？”。“如果發生停電怎麼辦？”，“如果拒絕客戶的信用卡怎麼辦？”，“如果倉庫發生火災怎麼辦？”。

對該領域具有濃厚的好奇心和好奇心，將帶您提出探索性和挑戰性的問題。這將帶您獲得有關該域的許多見解。

7.如果團隊正在困惑，請切換到單執行緒模式

混亂的探索是EventStorming的標誌之一，整個團隊都在這裡集體集思廣益。每個人都可以隨意將自己的想法，假設和疑慮用便籤貼在牆上。

混亂的探索對於EventStorming提供的許多發現至關重要。但是，有時精力不足，團隊感到困惑，或者由於許多可能的原因之一而沒有取得進展。你能為這個做什麼？

雖然在其他人觀看的同時只有一個人將便籤放在牆上是一種反模式，但是這種稱為單執行緒EventStorming的方法可以有效地幫助團隊達成一致並建立團隊動量。

此模式有一些變體，但是您可以嘗試以下方法：

1. 選一個人將便籤貼在牆上
2. 其他人圍坐在他周圍
3. 選擇一個特定的用例模型
4. 繼續努力，一次新增一個事件，以確保小組在繼續之前達成共識。如果小組陷入僵局，請做筆記並稍後返回
5. 如果還有其他疑問或疑慮，請記錄下來，稍後再返回-保持進度前進

在簡短的單執行緒會話之後，該小組將有許多想法和他們想更詳細地建模的其他方案。切換回混沌模式的好時機。

掌握事件儲存和微服務設計

瞭解您的業務領域是設計最佳軟體系統的關鍵。因此，提高對業務域進行建模的能力將增強您作為系統設計師的能力。

EventStorming是可用於對業務域進行建模的最佳工具之一。您對EventStorm的掌握越多，您就能構建出滿足業務需求的軟體系統，從而取得更大的成功。

五分鐘內您將無法掌握MasterStorming。但是，您越早開始學習，越多地練習，就會越快到達那裡。我們希望我們在本文中分享的技巧將有助於加速您的精通學習之路。

（banq評：事件風暴會議本身就是一種探索問題和答案是否存在的各種可能性，突破舒適區，追問原因，擁抱不確定性，用好奇心驅使創新： https://www.jdon.com/53327）