[{"data":1,"prerenderedAt":576},["ShallowReactive",2],{"article-\u002Farticles\u002Fdomain-storytelling":3},{"id":4,"title":5,"body":6,"date":561,"description":562,"excerpt":563,"extension":564,"meta":565,"navigation":566,"path":567,"seo":568,"stem":569,"tags":570,"__hash__":575},"articles\u002Farticles\u002Fdomain-storytelling.md","領域故事化（Domain Storytelling）：讓業務用說故事的方式講需求，再從故事裡找出上下文邊界",{"type":7,"value":8,"toc":544},"minimark",[9,19,27,32,35,113,116,146,149,153,156,163,170,173,176,180,216,219,258,268,271,278,281,285,288,294,344,347,361,364,371,374,377,403,418,422,425,496,503,506,538,541],[10,11,12,13,18],"p",{},"在 ",[14,15,17],"a",{"href":16},"\u002Farticles\u002Fddd-overview-strategic-tactical","DDD 概論"," 提到，DDD 的前提是真的理解業務，而理解業務的方法之一是 Event Storming。不過實際和業務同事坐下來時，我發現 Event Storming 對第一次參加的人有點門檻：要先解釋什麼是「領域事件」、為什麼要用過去式、橘色和藍色差在哪裡。",[10,20,21,22,26],{},"Domain Storytelling（領域故事化）是另一種協作建模的方法，門檻低很多：",[23,24,25],"strong",{},"請業務照著平常的工作講一個故事，主持人一邊聽一邊畫","。它來自 Stefan Hofer 和 Henning Schwentner，兩人在 2021 年出版了《Domain Storytelling》一書，把這套方法整理成完整的做法。",[28,29,31],"h2",{"id":30},"圖示語法用簡單的句子拼成故事","圖示語法：用簡單的句子拼成故事",[10,33,34],{},"Domain Storytelling 的圖只有幾種元素：",[36,37,38,54],"table",{},[39,40,41],"thead",{},[42,43,44,48,51],"tr",{},[45,46,47],"th",{},"元素",[45,49,50],{},"說明",[45,52,53],{},"例子",[55,56,57,69,80,91,102],"tbody",{},[42,58,59,63,66],{},[60,61,62],"td",{},"角色（Actor）",[60,64,65],{},"故事裡做事的人、群體或系統",[60,67,68],{},"買方、經紀人、屋主、業務系統",[42,70,71,74,77],{},[60,72,73],{},"工作物件（Work Object）",[60,75,76],{},"角色處理、傳遞、產生的東西",[60,78,79],{},"帶看紀錄、斡旋書、斡旋金",[42,81,82,85,88],{},[60,83,84],{},"活動（Activity）",[60,86,87],{},"連接角色和工作物件的箭頭，用動詞標示",[60,89,90],{},"預約、確認、轉交",[42,92,93,96,99],{},[60,94,95],{},"序號",[60,97,98],{},"標在活動上，表示故事的順序",[60,100,101],{},"①、②、③",[42,103,104,107,110],{},[60,105,106],{},"註解",[60,108,109],{},"補充說明、規則或疑問",[60,111,112],{},"「還價是另一個故事」",[10,114,115],{},"每一步都是一個簡單的句子：",[117,118,119,135],"blockquote",{},[10,120,121,124,125,124,128,131,132],{},[23,122,123],{},"角色"," → ",[23,126,127],{},"活動",[23,129,130],{},"工作物件"," →（介系詞）→ ",[23,133,134],{},"另一個角色",[10,136,137,138,141,142,145],{},"例如：買方 ",[23,139,140],{},"提出"," 斡旋 ",[23,143,144],{},"給"," 經紀人",[10,147,148],{},"句子越簡單越好。如果一句話需要「如果…就…否則…」才講得完，通常代表它其實是兩個故事。",[28,150,152],{"id":151},"例子從找房到斡旋","例子：從找房到斡旋",[10,154,155],{},"下面是我和一位資深經紀人訪談後畫出來的故事，描述一位買方從找到物件、看屋，到提出斡旋的過程：",[10,157,158],{},[159,160],"img",{"alt":161,"src":162},"房仲帶看到斡旋的領域故事圖：買方、經紀人、屋主三個角色各只出現一次，左上是網站、下方是業務系統，經紀人位在中間，所有往來都經過他。九個帶序號的箭頭組成故事，每一句是「角色、動詞、工作物件、介系詞、角色」：1. 買方在網站搜尋物件；2. 買方向經紀人預約帶看；3. 經紀人和屋主確認帶看時間；4. 經紀人陪同買方帶看物件；5. 經紀人在業務系統填寫帶看紀錄；6. 買方提出斡旋書與斡旋金給經紀人；7. 經紀人轉交斡旋書給屋主；8. 屋主簽回已接受的斡旋書給經紀人；9. 經紀人通知斡旋結果給買方。序號依顏色分成三段：1 是搜尋，2 到 5 是帶看，6 到 9 是斡旋，代表從故事找出的候選上下文","\u002Fimages\u002Farticles\u002Fdomain-storytelling-viewing-offer.svg",[10,164,165,166,169],{},"每個角色在圖上只出現一次，所以畫完一眼就能看出整體的形狀：",[23,167,168],{},"買方和屋主之間從來沒有直接往來，所有的東西都經過經紀人","。這在逐條的需求清單裡看不出來，但它解釋了為什麼經紀人總是很忙，也指出了之後可以改善的地方，例如通知斡旋結果能不能由系統自動發送。",[10,171,172],{},"畫的時候，經紀人講到第 5 步，我問「帶看紀錄寫在哪？」，答案是「以前寫紙本帶看單，現在用業務系統」。再追問「帶看紀錄之後誰會看？」，才知道店長每週會看帶看紀錄來決定哪些物件要調價。這些細節在需求文件裡完全沒有，卻直接影響帶看紀錄要存哪些欄位。",[28,174,175],{"id":175},"一場工作坊怎麼進行",[177,178,179],"h3",{"id":179},"參與者與分工",[181,182,183,194,200,210],"ul",{},[184,185,186,189,190,193],"li",{},[23,187,188],{},"說故事的人","：領域專家，例如資深經紀人、店長。最好是",[23,191,192],{},"實際做這件事的人","，而不是只知道規定的主管",[184,195,196,199],{},[23,197,198],{},"主持人（Moderator）","：引導對話、控制節奏，確保一次只講一步",[184,201,202,205,206,209],{},[23,203,204],{},"建模者（Modeler）","：負責畫圖，通常就是主持人自己。畫的時候要",[23,207,208],{},"大聲重述","每一句：「所以是經紀人把斡旋書交給屋主，對嗎？」",[184,211,212,215],{},[23,213,214],{},"聽眾","：開發人員、PO。主要聽，必要時提問",[177,217,218],{"id":218},"進行步驟",[220,221,222,228,234,240,246,252],"ol",{},[184,223,224,227],{},[23,225,226],{},"選一個具體的情境","：「一位買方看了物件後出價」，而不是「斡旋流程」。具體的情境才講得出具體的步驟",[184,229,230,233],{},[23,231,232],{},"從觸發點開始講","：「這件事是怎麼開始的？」",[184,235,236,239],{},[23,237,238],{},"一句一句畫","：每講一步就畫一步，畫完重述，對方確認後再講下一步",[184,241,242,245],{},[23,243,244],{},"遇到分支先記下來","：「如果屋主不接受呢？」先寫在註解上，等這個故事講完，再另外畫一個「屋主還價」的故事",[184,247,248,251],{},[23,249,250],{},"整個故事重講一遍","：照著序號從頭講一次，常常會在這時發現漏掉的步驟",[184,253,254,257],{},[23,255,256],{},"標出疑問和痛點","：例如「經紀人要手動通知所有斡旋人，常常漏掉」",[10,259,260,261,267],{},"一個故事通常 30 分鐘到 1 小時就能畫完。工具可以用白板，或是免費的線上工具 ",[14,262,266],{"href":263,"rel":264},"https:\u002F\u002Fegon.io\u002F",[265],"nofollow","Egon.io","，它內建 Domain Storytelling 的圖示，還可以逐步回放故事。",[177,269,270],{"id":270},"不要畫分支",[10,272,273,274,277],{},"這是我第一次畫時最常犯的錯。流程圖習慣畫「判斷」菱形，但 Domain Storytelling 刻意不畫分支：",[23,275,276],{},"一個故事只講一種情況","。屋主接受、屋主還價、斡旋過期，是三個不同的故事。",[10,279,280],{},"這樣做的好處是每張圖都很好讀，而且逼大家用具體的例子思考。要說清楚的情況越多，就畫越多張，而不是把一張圖畫成迷宮。",[28,282,284],{"id":283},"範圍因子先決定要畫哪一種故事","範圍因子：先決定要畫哪一種故事",[10,286,287],{},"開始之前，要先和參與者確認這次故事的「範圍」，書中整理了三個因子：",[10,289,290],{},[159,291],{"alt":292,"src":293},"Domain Storytelling 的三個範圍因子：第一是粒度，粗粒度描述從找房到成交的整個過程，大約十步，用來看全貌和找邊界，細粒度只描述斡旋這一段的每個細節，用來釐清規則和需求；第二是時間點，現況描述目前實際怎麼做，例如經紀人手動打電話通知所有斡旋人，未來描述導入新系統後要怎麼做，例如系統自動通知；第三是領域純度，純領域只講業務，不提任何軟體，例如經紀人記下買方反應，數位化則畫出系統扮演的角色，例如經紀人在業務系統填寫帶看紀錄","\u002Fimages\u002Farticles\u002Fdomain-storytelling-scope.svg",[36,295,296,309],{},[39,297,298],{},[42,299,300,303,306],{},[45,301,302],{},"因子",[45,304,305],{},"選項",[45,307,308],{},"用途",[55,310,311,322,333],{},[42,312,313,316,319],{},[60,314,315],{},"粒度（Granularity）",[60,317,318],{},"粗粒度／細粒度",[60,320,321],{},"粗粒度看全貌、找上下文邊界；細粒度釐清單一流程的規則",[42,323,324,327,330],{},[60,325,326],{},"時間點（Point in Time）",[60,328,329],{},"現況（As-is）／未來（To-be）",[60,331,332],{},"現況用來理解問題；未來用來討論新系統要怎麼改變工作方式",[42,334,335,338,341],{},[60,336,337],{},"領域純度（Domain Purity）",[60,339,340],{},"純領域（Pure）／數位化（Digitalized）",[60,342,343],{},"純領域只講業務，避免被現有系統限制；數位化畫出軟體扮演的角色",[10,345,346],{},"常見的組合是：",[181,348,349,355],{},[184,350,351,354],{},[23,352,353],{},"剛接觸一個領域","：粗粒度 + 現況 + 純領域，先理解業務本身",[184,356,357,360],{},[23,358,359],{},"要設計新系統","：細粒度 + 未來 + 數位化，討論系統要怎麼支援每一步",[10,362,363],{},"上面帶看的例子是「粗粒度、現況、數位化」：它涵蓋整個過程，描述目前的做法，而且畫出了網站和業務系統。",[10,365,366,367,370],{},"範圍因子要",[23,368,369],{},"在開始前講好","。如果有人在講現況，有人在講「理想上應該要…」，故事會一直被打斷，最後兩邊都畫不完。",[28,372,373],{"id":373},"從故事找出限界上下文",[10,375,376],{},"粗粒度的故事畫完後，可以在上面找出限界上下文的候選邊界。幾個常用的線索：",[181,378,379,385,391,397],{},[184,380,381,384],{},[23,382,383],{},"語言改變了","：前半段說「物件」指的是網站上的刊登內容，到斡旋階段，「物件」變成有權狀、有所有權人的交易標的",[184,386,387,390],{},[23,388,389],{},"工作物件換了","：步驟 2～5 圍繞著「帶看」和「帶看紀錄」，步驟 6～9 圍繞著「斡旋書」和「斡旋金」",[184,392,393,396],{},[23,394,395],{},"有明顯的交接或時間間隔","：買方看完屋，可能隔好幾天才決定斡旋，前後兩段的觸發條件完全不同",[184,398,399,402],{},[23,400,401],{},"負責的人或部門不同","：帶看是經紀人自己安排，斡旋涉及店長審核、斡旋金的保管，參與的人不一樣",[10,404,405,406,409,410,413,414,417],{},"把這些線索對照到序號上，就能把故事分成三段：步驟 1 是",[23,407,408],{},"搜尋","、步驟 2～5 是",[23,411,412],{},"帶看","、步驟 6～9 是",[23,415,416],{},"斡旋","，也就是範例圖中序號的三種顏色。這只是候選的邊界，還要再看業務的重要性、團隊分工等因素才會定案，這部分之後會另外整理。",[28,419,421],{"id":420},"和-event-storming-的比較","和 Event Storming 的比較",[10,423,424],{},"兩者都是協作建模，但適合的情境不太一樣：",[36,426,427,439],{},[39,428,429],{},[42,430,431,433,436],{},[45,432],{},[45,434,435],{},"Domain Storytelling",[45,437,438],{},"Event Storming",[55,440,441,452,463,474,485],{},[42,442,443,446,449],{},[60,444,445],{},"主軸",[60,447,448],{},"角色和工作物件，「誰對什麼做了什麼」",[60,450,451],{},"領域事件，「發生了什麼事」",[42,453,454,457,460],{},[60,455,456],{},"進行方式",[60,458,459],{},"一位主持人一邊聽一邊畫，一次講一個故事",[60,461,462],{},"所有人同時在牆上貼便利貼",[42,464,465,468,471],{},[60,466,467],{},"適合人數",[60,469,470],{},"少，3～6 人",[60,472,473],{},"多，可以 10 人以上",[42,475,476,479,482],{},[60,477,478],{},"擅長",[60,480,481],{},"深入一個流程、看出人和人之間的交接",[60,483,484],{},"一次看到整個業務的全貌，發現部門之間的落差",[42,486,487,490,493],{},[60,488,489],{},"門檻",[60,491,492],{},"低，像訪談",[60,494,495],{},"要先說明規則，主持需要經驗",[10,497,498,499,502],{},"我的做法是：",[23,500,501],{},"剛接觸一個領域時先用 Domain Storytelling 和一兩位專家訪談","，對業務有基本理解後，再找更多部門一起跑 Event Storming。兩者不衝突，用 Domain Storytelling 找到的角色和工作物件，在 Event Storming 時也很容易轉成事件和命令。",[28,504,505],{"id":505},"注意事項",[181,507,508,514,520,526,532],{},[184,509,510,513],{},[23,511,512],{},"用具體的例子","：「王先生上週六看了信義區那間三房」比「使用者瀏覽物件」好講得多，也更容易發現例外",[184,515,516,519],{},[23,517,518],{},"不要畫成畫面流程","：「點擊預約按鈕、跳出日曆」是 UI 設計，不是業務。即使是數位化的故事，也只畫「經紀人在業務系統填寫帶看紀錄」",[184,521,522,525],{},[23,523,524],{},"建模者不要自己補內容","：覺得少了一步就問，不要自己畫上去。建模者的假設常常就是需求誤解的來源",[184,527,528,531],{},[23,529,530],{},"一張圖不要太長","：步驟超過 20 步就很難讀，可以把細節拆成另一個細粒度的故事",[184,533,534,537],{},[23,535,536],{},"畫完要保存","：拍照或匯出，放進團隊的文件。之後新成員要理解業務時，這些故事比任何規格書都好懂",[28,539,540],{"id":540},"一句話總結",[10,542,543],{},"Domain Storytelling 用「角色、活動、工作物件」的簡單句子，讓領域專家照著真實的工作講故事、主持人一邊畫一邊確認；一個故事只講一種情況，開始前先決定粒度、時間點與領域純度，畫完後再從語言、工作物件與交接點的變化，找出限界上下文的候選邊界。",{"title":545,"searchDepth":546,"depth":546,"links":547},"",2,[548,549,550,556,557,558,559,560],{"id":30,"depth":546,"text":31},{"id":151,"depth":546,"text":152},{"id":175,"depth":546,"text":175,"children":551},[552,554,555],{"id":179,"depth":553,"text":179},3,{"id":218,"depth":553,"text":218},{"id":270,"depth":553,"text":270},{"id":283,"depth":546,"text":284},{"id":373,"depth":546,"text":373},{"id":420,"depth":546,"text":421},{"id":505,"depth":546,"text":505},{"id":540,"depth":546,"text":540},"2024-03-19","在 DDD 概論 提到，DDD 的前提是真的理解業務，而理解業務的方法之一是 Event Storming。不過實際和業務同事坐下來時，我發現 Event Storming 對第一次參加的人有點門檻：要先解釋什麼是「領域事件」、為什麼要用過去式、橘色和藍色差在哪裡。",null,"md",{},true,"\u002Farticles\u002Fdomain-storytelling",{"title":5,"description":562},"articles\u002Fdomain-storytelling",[571,572,435,573,574],"DDD","領域驅動設計","需求分析","架構設計","Kczi9D4cxItwNOPZ0YUVxZECeMYiU80LLUgTj9Qxit0",1792959150397]