2024年3月19日
領域故事化（Domain Storytelling）：讓業務用說故事的方式講需求，再從故事裡找出上下文邊界
在 DDD 概論 提到，DDD 的前提是真的理解業務，而理解業務的方法之一是 Event Storming。不過實際和業務同事坐下來時，我發現 Event Storming 對第一次參加的人有點門檻：要先解釋什麼是「領域事件」、為什麼要用過去式、橘色和藍色差在哪裡。
Domain Storytelling（領域故事化）是另一種協作建模的方法，門檻低很多：請業務照著平常的工作講一個故事，主持人一邊聽一邊畫。它來自 Stefan Hofer 和 Henning Schwentner，兩人在 2021 年出版了《Domain Storytelling》一書，把這套方法整理成完整的做法。
圖示語法：用簡單的句子拼成故事
Domain Storytelling 的圖只有幾種元素：
| 元素 | 說明 | 例子 |
|---|---|---|
| 角色（Actor） | 故事裡做事的人、群體或系統 | 買方、經紀人、屋主、業務系統 |
| 工作物件（Work Object） | 角色處理、傳遞、產生的東西 | 帶看紀錄、斡旋書、斡旋金 |
| 活動（Activity） | 連接角色和工作物件的箭頭，用動詞標示 | 預約、確認、轉交 |
| 序號 | 標在活動上，表示故事的順序 | ①、②、③ |
| 註解 | 補充說明、規則或疑問 | 「還價是另一個故事」 |
每一步都是一個簡單的句子：
角色 → 活動 → 工作物件 →（介系詞）→ 另一個角色
例如：買方 提出 斡旋 給 經紀人
句子越簡單越好。如果一句話需要「如果…就…否則…」才講得完，通常代表它其實是兩個故事。
例子：從找房到斡旋
下面是我和一位資深經紀人訪談後畫出來的故事，描述一位買方從找到物件、看屋，到提出斡旋的過程：
每個角色在圖上只出現一次，所以畫完一眼就能看出整體的形狀：買方和屋主之間從來沒有直接往來，所有的東西都經過經紀人。這在逐條的需求清單裡看不出來，但它解釋了為什麼經紀人總是很忙，也指出了之後可以改善的地方，例如通知斡旋結果能不能由系統自動發送。
畫的時候，經紀人講到第 5 步，我問「帶看紀錄寫在哪？」，答案是「以前寫紙本帶看單，現在用業務系統」。再追問「帶看紀錄之後誰會看？」，才知道店長每週會看帶看紀錄來決定哪些物件要調價。這些細節在需求文件裡完全沒有，卻直接影響帶看紀錄要存哪些欄位。
一場工作坊怎麼進行
參與者與分工
- 說故事的人：領域專家，例如資深經紀人、店長。最好是實際做這件事的人，而不是只知道規定的主管
- 主持人（Moderator）：引導對話、控制節奏，確保一次只講一步
- 建模者（Modeler）：負責畫圖，通常就是主持人自己。畫的時候要大聲重述每一句：「所以是經紀人把斡旋書交給屋主，對嗎？」
- 聽眾：開發人員、PO。主要聽，必要時提問
進行步驟
- 選一個具體的情境：「一位買方看了物件後出價」，而不是「斡旋流程」。具體的情境才講得出具體的步驟
- 從觸發點開始講：「這件事是怎麼開始的？」
- 一句一句畫：每講一步就畫一步，畫完重述，對方確認後再講下一步
- 遇到分支先記下來：「如果屋主不接受呢？」先寫在註解上，等這個故事講完，再另外畫一個「屋主還價」的故事
- 整個故事重講一遍：照著序號從頭講一次，常常會在這時發現漏掉的步驟
- 標出疑問和痛點：例如「經紀人要手動通知所有斡旋人，常常漏掉」
一個故事通常 30 分鐘到 1 小時就能畫完。工具可以用白板，或是免費的線上工具 Egon.io，它內建 Domain Storytelling 的圖示，還可以逐步回放故事。
不要畫分支
這是我第一次畫時最常犯的錯。流程圖習慣畫「判斷」菱形，但 Domain Storytelling 刻意不畫分支：一個故事只講一種情況。屋主接受、屋主還價、斡旋過期，是三個不同的故事。
這樣做的好處是每張圖都很好讀，而且逼大家用具體的例子思考。要說清楚的情況越多，就畫越多張，而不是把一張圖畫成迷宮。
範圍因子：先決定要畫哪一種故事
開始之前，要先和參與者確認這次故事的「範圍」，書中整理了三個因子：
| 因子 | 選項 | 用途 |
|---|---|---|
| 粒度（Granularity） | 粗粒度／細粒度 | 粗粒度看全貌、找上下文邊界；細粒度釐清單一流程的規則 |
| 時間點（Point in Time） | 現況（As-is）／未來（To-be） | 現況用來理解問題；未來用來討論新系統要怎麼改變工作方式 |
| 領域純度（Domain Purity） | 純領域（Pure）／數位化（Digitalized） | 純領域只講業務，避免被現有系統限制；數位化畫出軟體扮演的角色 |
常見的組合是：
- 剛接觸一個領域：粗粒度 + 現況 + 純領域，先理解業務本身
- 要設計新系統：細粒度 + 未來 + 數位化，討論系統要怎麼支援每一步
上面帶看的例子是「粗粒度、現況、數位化」：它涵蓋整個過程，描述目前的做法，而且畫出了網站和業務系統。
範圍因子要在開始前講好。如果有人在講現況，有人在講「理想上應該要…」，故事會一直被打斷，最後兩邊都畫不完。
從故事找出限界上下文
粗粒度的故事畫完後，可以在上面找出限界上下文的候選邊界。幾個常用的線索：
- 語言改變了：前半段說「物件」指的是網站上的刊登內容，到斡旋階段，「物件」變成有權狀、有所有權人的交易標的
- 工作物件換了：步驟 2～5 圍繞著「帶看」和「帶看紀錄」，步驟 6～9 圍繞著「斡旋書」和「斡旋金」
- 有明顯的交接或時間間隔：買方看完屋，可能隔好幾天才決定斡旋，前後兩段的觸發條件完全不同
- 負責的人或部門不同：帶看是經紀人自己安排，斡旋涉及店長審核、斡旋金的保管，參與的人不一樣
把這些線索對照到序號上，就能把故事分成三段：步驟 1 是搜尋、步驟 2～5 是帶看、步驟 6～9 是斡旋，也就是範例圖中序號的三種顏色。這只是候選的邊界，還要再看業務的重要性、團隊分工等因素才會定案，這部分之後會另外整理。
和 Event Storming 的比較
兩者都是協作建模，但適合的情境不太一樣：
| Domain Storytelling | Event Storming | |
|---|---|---|
| 主軸 | 角色和工作物件，「誰對什麼做了什麼」 | 領域事件，「發生了什麼事」 |
| 進行方式 | 一位主持人一邊聽一邊畫，一次講一個故事 | 所有人同時在牆上貼便利貼 |
| 適合人數 | 少，3～6 人 | 多，可以 10 人以上 |
| 擅長 | 深入一個流程、看出人和人之間的交接 | 一次看到整個業務的全貌，發現部門之間的落差 |
| 門檻 | 低，像訪談 | 要先說明規則，主持需要經驗 |
我的做法是：剛接觸一個領域時先用 Domain Storytelling 和一兩位專家訪談，對業務有基本理解後，再找更多部門一起跑 Event Storming。兩者不衝突，用 Domain Storytelling 找到的角色和工作物件，在 Event Storming 時也很容易轉成事件和命令。
注意事項
- 用具體的例子：「王先生上週六看了信義區那間三房」比「使用者瀏覽物件」好講得多，也更容易發現例外
- 不要畫成畫面流程：「點擊預約按鈕、跳出日曆」是 UI 設計，不是業務。即使是數位化的故事，也只畫「經紀人在業務系統填寫帶看紀錄」
- 建模者不要自己補內容：覺得少了一步就問，不要自己畫上去。建模者的假設常常就是需求誤解的來源
- 一張圖不要太長：步驟超過 20 步就很難讀，可以把細節拆成另一個細粒度的故事
- 畫完要保存：拍照或匯出，放進團隊的文件。之後新成員要理解業務時，這些故事比任何規格書都好懂
一句話總結
Domain Storytelling 用「角色、活動、工作物件」的簡單句子，讓領域專家照著真實的工作講故事、主持人一邊畫一邊確認；一個故事只講一種情況，開始前先決定粒度、時間點與領域純度，畫完後再從語言、工作物件與交接點的變化，找出限界上下文的候選邊界。