上一篇文章簡單的理解完 Domain-Driven Design 後，接下來這篇文章我們來談談戰略層級的實際上我們要幹啥，其中 Event Storming 應該是目前最常見的 DDD 戰略工具。

Event Storming 的產出

Event Storming 簡單的說，它就是將我們的 problem space 分析成 solve space 的方法，最後的產出就是下面這二張圖，然後還有一些思想上的產出 :

• 撰寫這包含很多 Event Storming 元素的 Miro。
• 這個東西是產品、工程、營運一起完成的東西，所以可以讓三方思想有一定的基本對齊。
• 很多流程上的問題可以提早被發現。
• 產品、工程、營運感情可以好一點……，因為會覺得這個是一起討論出來的東西。

下圖我們家跑完下面 step 1 ~ step 7 的範例結果，請讓我打一下馬賽克。

然後整理一下後，工程大概就可以用它來建模了，然後裡面黃色就是 aggregate，也可以理解成我們之前提的 domain model，然後兩邊 bounded context 就是切分的最小單位。

Event Storming Workshop 的過程

參加人員: 營運、產品、工程
時間: 大約 2 ~ 3 小時
裝備: 酒

Step 1. 就先解釋一下 Event Storming 的整個流程 + 說明以下的圖

然後我都叫他們只要帶這腦袋來就好，如果沒跑過的人。

Step 2.請 PM 們說明業務背景與目標

這個我自已覺得是目前比較模糊的地方，也是 pm 們最常問我的問題，就是要如何準備這一塊，然後這裡又可以分為以下兩個類型的需求:

1. 改版現有的東西。
2. 新的需求。

其中第 1 種通常比較好處理，因為我們比較像是用 event storming 來理清楚現有的東西與實際上我們不知道營運的那一塊流程，所以這時通常就說清楚，我們要跑現有的東西的 event storming 就好，然後如果 pm 有準備一些決定好要改的草稿也可以一起發出去，然後現場就直接 review 一次後就 go。

然後第 2 種是我自已有點不確定的一塊，這個東西通常是 pm PRD 有個草稿後，我們才會安排個時間跑，因為沒有草稿我們事實上也不知道要幹啥，但草稿要寫到怎麼樣呢 ? 我自已是覺得就是有問題空間，也就是為什麼要做這個需求，希望達成什麼結果之類的。但是我這裡也不確定要如何做比較好，就只能拿我們試過的來說說 ~

Step 3. Domain Event 腦袋風爆 ( 橘色 )

這裡會先簡單說明一下 Domain Event 的意思，並且也會簡單說個範例給朋朋們，然後通常是我會先貼上第一張便利貼上去，然後接下來這些人就會自動的動起來，然後其中有幾點要注意 :

1. 一定要是『 已 』開頭的，例如已付款、已看課、已通知啥的。
2. 這個事件不一定要是系統有的還是營運日常工作之類的，反正你們覺得重要的事件就貼啥。
3. 這個階段就是想到啥就貼啥。
4. 會定時，大概先抓個 20 ~ 30 分鐘，不過主要還是看討論的東西大小。

備註: 這裡事實上不太建議放 question，因為後來發現很多情況下，都是在 step 4、5 會放的東西。

Step 4. 整理 Domain Event + 時間軸 + 然後一邊順這說故事

在這個過程有幾個重點 :

1. 先從最前面的開始放，然後再根據時間排序。
2. 整理重複的，只留一張 ( 還有字太醜的問一下是誰寫的 )
3. 然後有沒有比較明顯的 Pivot，例如我們是已開課、已開始募資這種。

Step 5. 然後找出這張圖除了 Domain Event 與 Policy 外的東西

主要會是以下幾個:

• Command ( decision ): 就是某個 actor 觸發了這個 command，然後產生 domain event。
• Actor: 就是誰獨發了 command。
• Read Model: 就是需要這些資料，來讓 actor 決定觸發某個 command，然後這裡我有一點變化，就是我通常會和他們說，就是使用者在什麼平台上，看到什麼資料後，決定觸發這個 command，然後我通常這裡會請 UI/UX 們注意一下這裡，就代表這個地方通常需要設計。
• External: 外部系統，例如第三方金流啥的。
• Question: 就是有啥問題就貼

Step 6. 這裡通常還會需要整理一次，順一次，然後一邊回答 Question，有些 Policy 可能就會自動產生出來

Policy 正常的情況就是，有時 Domain Event 產生後，可能也產生的一些業務事件，例如付款完成後，我們可能需要寄信通知、開始進行分潤之類的，那這個就是 policy，然後通常它會呼叫另一個 command 然後產生 domain event。

Step 7. 找出 Aggregate，然後集合起來

就是叫他們想個名詞 ( Ubiquitous Language )，然後這個我覺得對 pm 與營運人員比較難理解，所以我都說，它就是可以產生出 domain event 的程式碼的模型……

Step 8. 找出 Bounded Context + Context Map

這個地方我事實上碰到一個難點，那就是我很常聽到:

沒有 Bounded Context

就是它們覺得這東西就是包在一起的，例如就很像是我們開發它就是一個 course service 的概念，裡面包山包海，然後這時我通常會問幾句話:

• 有沒有那個 domain event 是之前跑 event storming 有出現過的。
• 有沒有那些 domain event 你覺得是很通用的，可以讓其它 BC 使用的。
• 如果一個 aggregat 太多 domain event 有沒有辦法在拆成一個呢 ?

接下來確認好 bounded context，然後就會確認他們的方向或關係。

然後最後大概會產出以下的結果

Step 9. 最後會判斷 Core Domain、Supporting SubDomain、Generic SubDomain

最後的一步就是判斷那些是 Core Domain、Supporting SubDomain、Generic SubDomain :

• Core Domain : 最有價值、最核心、花費最大力氣在開發。
• Supporting SubDomain : 提供 core domain 所需的功能。
• Generic SubDomain : 所有系統都需要用到他，但不是核心，也就是說丟給外包也可以的部份。

就……我也不太知道如何說，但反正就討論完很容易判斷，但是不是好的，我也不確定……

Q&A

1. 何時舉行 Event Storming 的時間 ?

我們現在是跑 scrum，但是跑 event storming 的時間事實上不確定，因為通常會是我事先知道之後一個月要做啥，然後我會判斷它的複雜度會不會需要跑 event storming，接下來就是在 sprint 某個時間舉行。( 準確的說就是他沒放在 sprint 流程，理想上我是希望，但現在偶們有點難 )

至於複雜度的判斷法，如果都是 Query 情境的就不太會 ( 但我也想試一次，說不定會有不同的發現 )，然後如果是其它大概就是靠經驗吧，就如果聽到某個東西，然後腦袋覺得淺玩意或有點麻煩的，就不太會跑，然後其它就是要。我也沒啥公式可說 ~ 然後這也是我們其它團隊要導入的其中一個問題，沒人可以判斷。

然後順到說一下，通常都是結束後，才會有正式的 PRD、User Story、UI/UX mockup 之類的，因為 PM 與 UI/UX 們通常會用這個來進行一些調整。

對了，上面是我們家的情況，我不覺得這個是每間都這樣。

2. 有人數限制嗎 ?

不確定，因為要看我們要 storming 的專案，如果很大，像是我們之前要跑整個 hahow 課程的整個流程的，那至少就有 15 ~ 20 個人左右參加，然後這個時後我通常就會分 3 ~ 4 組，然後請有經驗的人帶，以組為單位來產生便條紙。但真的累，而且那種情況 3 小時一定不夠。

3. Event Storming 如何轉成程式碼 ?

下篇。

4. Event Storming 產出後的每個 Domain Event 適合當一個 User Story 嗎 ?

我沒試過，但我自已是覺得合適的，但是因為我們家 PM 很習慣會根據 UI/UX 出的設計稿，然後根據畫面來切 user story，所以我也沒試過。

然後我查了《Introducing EventStorming An act of deliberate collective learning 》它書中的確也有提到 From EventStorming to UserStories 的東西，所以看起應該是行。

5. 要如何開始呢 ?

就不要臉先叫人試一次吧，沒跑過看在多書都沒啥用。

6. 所有人都要參數 Step 1 ~ 9 嗎 ?

希望，但如果營運或 PM 沒啥時間的話，至少要到 step 6.

7. 要如何找營運的人呢 ?

看你的面子夠不夠，夠的話很簡單。如果不夠請 PM 們叫 ~ 不過我認真說，平常真的要打好關係，你幫他一下，他幫你一下，不要什麼東西都卡，然後一直高高在上的感覺，別忘了一個好的系統前提是有人用、有人幫你推、有人幫你賣、有人幫你維護。

小結

最後總結一下，如果用一句話來總結下面的流程就是:

Actor 根據 Read Model ( UI )，決定進行 Command，然後產生 Domain Event，並且它會根據 Policy 來觸發其它 Command

然後接下來我都會用這個來解釋 Aggregate :

這個模型 ( Aggregate ) 它的職責就是會產生這些 Domain Event

最後來說說心得。

Event Storming 我們跑起來很有感，可以讓我們工程、產品、營運的朋朋們有了一個可以一起討論流程、重要事件的過程，並且我們也在跑的途中發現，很多我們少接觸的營運朋朋們，他們覺得很重要的 Domain Event 但是卻發現沒有在原本預計的規畫中，這也導致花了很多時間要手動來處理那些事情。

雖然 event storming 有些人會說他不是許願池，但是換個角度想，一個營運覺得很重要的 Domain Event，但是卻沒有在這個系統中，那是不是有什麼問題 ? 你想想如果產品規畫做的 Domain Event 都是營運們覺得不重要的東西，那這個系統是好嗎 ?

營運 + 產品 + 工程 = 才會有一個好的系統