[{"data":1,"prerenderedAt":757},["ShallowReactive",2],{"article-\u002Farticles\u002Fevent-storming-workshop":3},{"id":4,"title":5,"body":6,"date":741,"description":742,"excerpt":743,"extension":744,"meta":745,"navigation":746,"path":747,"seo":748,"stem":749,"tags":750,"__hash__":756},"articles\u002Farticles\u002Fevent-storming-workshop.md","Event Storming 怎麼跑？從準備、Big Picture 的七個步驟，到 Process Modeling 的便利貼語法",{"type":7,"value":8,"toc":712},"minimark",[9,28,32,35,102,109,112,116,123,151,154,157,189,192,195,202,311,318,321,324,344,348,354,358,361,365,372,386,389,393,396,419,426,430,437,449,453,456,463,467,474,478,492,496,503,506,509,529,533,536,556,559,573,576,580,590,593,631,634,706,709],[10,11,12,17,18,22,23,27],"p",{},[13,14,16],"a",{"href":15},"\u002Farticles\u002Fddd-overview-strategic-tactical","DDD 概論"," 簡單介紹過 Event Storming，",[13,19,21],{"href":20},"\u002Farticles\u002Fdomain-storytelling","Domain Storytelling"," 那篇也比較過兩者的差別。這段時間實際主持了幾場，發現光知道「橘色是事件、藍色是命令」遠遠不夠，",[24,25,26],"strong",{},"一場 Event Storming 成不成功，八成取決於準備和主持","。這篇把流程完整整理一次。",[29,30,31],"h2",{"id":31},"三種層次",[10,33,34],{},"Event Storming 由 Alberto Brandolini 提出，依目的不同分成三種層次：",[36,37,38,57],"table",{},[39,40,41],"thead",{},[42,43,44,48,51,54],"tr",{},[45,46,47],"th",{},"層次",[45,49,50],{},"目的",[45,52,53],{},"參與者",[45,55,56],{},"時間",[58,59,60,75,89],"tbody",{},[42,61,62,66,69,72],{},[63,64,65],"td",{},"Big Picture",[63,67,68],{},"看清楚整個業務的全貌，找出問題與邊界",[63,70,71],{},"各部門的領域專家、PO、開發人員",[63,73,74],{},"半天到一天",[42,76,77,80,83,86],{},[63,78,79],{},"Process Modeling",[63,81,82],{},"拆解一個流程，弄清楚每一步的規則",[63,84,85],{},"該流程的領域專家、PO、開發人員",[63,87,88],{},"2～4 小時",[42,90,91,94,97,100],{},[63,92,93],{},"Software Design",[63,95,96],{},"設計聚合、命令與事件，直接對應到程式",[63,98,99],{},"開發人員為主，領域專家在旁回答問題",[63,101,88],{},[10,103,104,105,108],{},"三者是",[24,106,107],{},"由寬到窄","的關係：Big Picture 找出最值得處理的流程，Process Modeling 把那個流程拆清楚，Software Design 再把它變成程式的設計。這篇主要介紹前兩種。",[29,110,111],{"id":111},"準備",[113,114,115],"h3",{"id":115},"找對人",[10,117,118,119,122],{},"最重要的一件事。Event Storming 的價值來自",[24,120,121],{},"不同部門的知識碰在一起","，所以要找：",[124,125,126,133,139,145],"ul",{},[127,128,129,132],"li",{},[24,130,131],{},"真正做事的領域專家","：資深經紀人、店長、負責簽約的同事、財務。只找主管來，常常只會聽到「規定上應該怎麼做」",[127,134,135,138],{},[24,136,137],{},"開發人員","：他們會問出業務沒想過的問題，例如「斡旋過期的那一刻，系統要做什麼？」",[127,140,141,144],{},[24,142,143],{},"PO","：最後要決定優先順序的人",[127,146,147,150],{},[24,148,149],{},"主持人","：最好不是領域專家，也不是要做決定的人，才能保持中立",[10,152,153],{},"Big Picture 大約 8～15 人最適合。少於 5 人看不到全貌，超過 20 人很難讓每個人都參與。",[113,155,156],{"id":156},"準備空間與材料",[124,158,159,165,171,177,183],{},[127,160,161,164],{},[24,162,163],{},"一面很長的牆","：至少 6～8 公尺，貼上大張的海報紙或白報紙卷。牆不夠長，時間軸會被迫折行，就看不出全貌",[127,166,167,170],{},[24,168,169],{},"把椅子移開","：大家站著才會走動、會靠過去看別人貼了什麼。坐著開會很快就變成一兩個人在講",[127,172,173,176],{},[24,174,175],{},"大量的便利貼","：橘色要準備最多，一場 Big Picture 用掉幾百張很正常",[127,178,179,182],{},[24,180,181],{},"粗的黑色簽字筆","：每人一支。不要用原子筆，字太小，遠一點就看不到；字寫不下也會逼大家寫得簡潔",[127,184,185,188],{},[24,186,187],{},"圖例","：把每種顏色代表什麼，先貼在牆的一角",[10,190,191],{},"遠端進行可以用 Miro 這類線上白板，先把時間軸和圖例準備好。但線上很難達到實體的效果：大家容易各自安靜地貼，討論變少，主持人要更主動點名。",[29,193,194],{"id":194},"便利貼的顏色與語法",[10,196,197],{},[198,199],"img",{"alt":200,"src":201},"Event Storming 的便利貼圖例與 Process Modeling 語法。上方是八種便利貼：橘色是領域事件，業務上發生的事，用過去式，例如斡旋已提出；藍色是命令，使用者的意圖或決定，例如提出斡旋；小張黃色是角色，做出命令的人，例如買方；淡紫色是政策，每當某事件發生就做某事的自動反應；綠色是讀取模型，做決定前需要看的資訊；大張黃色是聚合或系統，接收命令並守住規則；粉紅色是外部系統，例如簡訊服務；桃紅色是熱點，代表疑問、衝突或痛點。下方是一條完整的語法鏈：買方看了讀取模型「物件資訊與目前斡旋狀態」後，發出「提出斡旋」命令，由斡旋聚合檢查規則，產生「斡旋已提出」事件；事件觸發政策「每當斡旋已提出，就通知屋主」，發出「通知屋主」命令，交給外部的簡訊服務；同時事件會更新讀取模型","\u002Fimages\u002Farticles\u002Fevent-storming-grammar.svg",[36,203,204,217],{},[39,205,206],{},[42,207,208,211,214],{},[45,209,210],{},"顏色",[45,212,213],{},"元素",[45,215,216],{},"說明",[58,218,219,234,245,256,267,278,289,300],{},[42,220,221,224,227],{},[63,222,223],{},"橘色",[63,225,226],{},"領域事件（Domain Event）",[63,228,229,230,233],{},"業務上發生、而且有人在意的事，",[24,231,232],{},"用過去式","：「斡旋已提出」",[42,235,236,239,242],{},[63,237,238],{},"藍色",[63,240,241],{},"命令（Command）",[63,243,244],{},"使用者的意圖或決定：「提出斡旋」",[42,246,247,250,253],{},[63,248,249],{},"小張黃色",[63,251,252],{},"角色（Actor）",[63,254,255],{},"發出命令的人：買方、經紀人",[42,257,258,261,264],{},[63,259,260],{},"淡紫色",[63,262,263],{},"政策（Policy）",[63,265,266],{},"「每當…就…」的反應規則，可以是自動的，也可以是某人的固定做法",[42,268,269,272,275],{},[63,270,271],{},"綠色",[63,273,274],{},"讀取模型（Read Model）",[63,276,277],{},"角色做決定前需要看到的資訊",[42,279,280,283,286],{},[63,281,282],{},"大張黃色",[63,284,285],{},"聚合／系統",[63,287,288],{},"接收命令、檢查規則、產生事件的地方",[42,290,291,294,297],{},[63,292,293],{},"粉紅色",[63,295,296],{},"外部系統",[63,298,299],{},"不在我們控制範圍內的系統：簡訊服務、銀行",[42,301,302,305,308],{},[63,303,304],{},"桃紅色（斜貼）",[63,306,307],{},"熱點（Hot Spot）",[63,309,310],{},"疑問、衝突、痛點，任何人隨時都可以貼",[10,312,313,314,317],{},"各團隊的顏色不完全一樣，重要的是",[24,315,316],{},"同一場裡保持一致","，並把圖例貼在牆上。",[113,319,320],{"id":320},"為什麼事件要用過去式",[10,322,323],{},"「斡旋已提出」和「提出斡旋」看起來只差兩個字，但意義完全不同：",[124,325,326,332,338],{},[127,327,328,331],{},[24,329,330],{},"過去式代表已經發生的事實","，不能被拒絕、不能被撤銷，只能用另一個事件來抵銷（例如「斡旋已撤回」）",[127,333,334,337],{},[24,335,336],{},"它逼大家講業務結果","，而不是系統動作。「資料已寫入資料庫」、「API 已呼叫」不是領域事件，業務人員看不懂，也不在意",[127,339,340,343],{},[24,341,342],{},"事件是最容易達成共識的","：大家對「該怎麼做」可能意見不同，但對「發生了什麼」通常很快有共識",[29,345,347],{"id":346},"big-picture七個步驟","Big Picture：七個步驟",[10,349,350],{},[198,351],{"alt":352,"src":353},"Big Picture 的牆面示意，房仲業務的事件時間軸局部。時間軸由左到右分成四段：委託與刊登有委託已簽訂、物件已拍照、物件已上架；帶看有帶看已預約、帶看已完成、帶看紀錄已填寫；斡旋有斡旋已提出、斡旋金已收取、斡旋已轉交屋主、斡旋已接受，以及另一種結果斡旋已過期；簽約交屋有買賣契約已簽訂、已交屋、服務費已收取。物件已上架、斡旋已接受、買賣契約已簽訂是關鍵事件，用垂直線把時間軸分段，各段上方標出屋主、經紀人、買方、代書等角色，以及外部系統銀行。牆面下方貼著三個熱點：物件改價後進行中的斡旋怎麼辦、多組斡旋時誰優先、斡旋已接受算不算成交。最底部列出七個步驟：混亂探索、整理時間軸、關鍵事件與邊界、人與系統、熱點、走一遍與倒著走、問題與機會投票","\u002Fimages\u002Farticles\u002Fevent-storming-big-picture.svg",[113,355,357],{"id":356},"_0-開場10-分鐘","0. 開場（10 分鐘）",[10,359,360],{},"說明今天的目的、範圍（例如「從屋主委託到交屋」）、規則，以及圖例。範圍的起點和終點要講清楚，否則會有人從公司成立開始講。",[113,362,364],{"id":363},"_1-混亂探索2030-分鐘","1. 混亂探索（20～30 分鐘）",[10,366,367,368,371],{},"每個人",[24,369,370],{},"各自","把自己知道的領域事件寫在橘色便利貼上，大致依時間順序貼到牆上。",[124,373,374,380],{},[127,375,376,379],{},[24,377,378],{},"不討論、不糾正","：這個階段要的是數量，重複的、寫錯的之後再處理",[127,381,382,385],{},[24,383,384],{},"自己負責的部分就貼","：財務只知道服務費怎麼收，那就貼那一段",[10,387,388],{},"一開始大家會很拘謹，主持人可以自己先貼幾張示範，再點名：「店長，斡旋那一段您最熟，可以先貼嗎？」",[113,390,392],{"id":391},"_2-整理時間軸3060-分鐘","2. 整理時間軸（30～60 分鐘）",[10,394,395],{},"大家一起把便利貼排成一條合理的時間軸：",[124,397,398,407,413],{},[127,399,400,403,404],{},[24,401,402],{},"合併重複的","：兩張寫法不同但意思一樣的，選一個大家都接受的說法。如果合不起來，代表其實是兩件事，或是語言有分歧，",[24,405,406],{},"貼一張熱點",[127,408,409,412],{},[24,410,411],{},"補上缺漏","：時間軸上出現跳躍，問「這兩件事中間還發生了什麼？」",[127,414,415,418],{},[24,416,417],{},"平行的流程分成泳道","：例如「帶看」和「斡旋金保管」可以同時進行，上下分開排",[10,420,421,422,425],{},"這個階段最容易吵起來，例如業務認為「斡旋已接受」就是成交，財務認為「買賣契約已簽訂」才算。",[24,423,424],{},"不需要當場吵出結果","，貼一張熱點，繼續往下走。",[113,427,429],{"id":428},"_3-找出關鍵事件與邊界20-分鐘","3. 找出關鍵事件與邊界（20 分鐘）",[10,431,432,433,436],{},"找出幾個",[24,434,435],{},"改變業務階段","的事件，例如「物件已上架」、「斡旋已接受」、「買賣契約已簽訂」，在它們後面用膠帶或垂直線把時間軸分段，並在每段上方寫一個名稱。",[10,438,439,440,443,444,448],{},"這些分段就是子域或限界上下文的",[24,441,442],{},"候選","。之後可以再用 ",[13,445,447],{"href":446},"\u002Farticles\u002Fddd-subdomains-bounded-context","子域劃分"," 那篇的方法，判斷每一段是核心、支撐還是通用。",[113,450,452],{"id":451},"_4-補上人與系統20-分鐘","4. 補上人與系統（20 分鐘）",[10,454,455],{},"在事件旁邊貼上小張黃色的角色，以及粉紅色的外部系統：誰讓這件事發生的？依賴了哪個系統？",[10,457,458,459,462],{},"這一步常常會發現",[24,460,461],{},"交接的問題","，例如「斡旋金已收取」之後，到底是經紀人還是店長保管？兩個人的說法不一樣。",[113,464,466],{"id":465},"_5-標出熱點全程","5. 標出熱點（全程）",[10,468,469,470,473],{},"熱點不是一個獨立的階段，而是",[24,471,472],{},"整場都可以貼","。任何疑問、衝突、「這裡常常出問題」都貼上去。熱點越多，代表這場越有價值：這些問題本來就存在，只是之前沒被看到。",[113,475,477],{"id":476},"_6-走一遍倒著走30-分鐘","6. 走一遍、倒著走（30 分鐘）",[124,479,480,486],{},[127,481,482,485],{},[24,483,484],{},"走一遍（Explicit Walk-through）","：請一位參與者從頭講一次整條時間軸，其他人邊聽邊補充。講不下去的地方，通常就是缺了事件",[127,487,488,491],{},[24,489,490],{},"倒著走（Reverse Narrative）","：從最後一個事件往回問「要發生這件事，前面必須先發生什麼？」。往前走容易只講順利的情況，倒著走比較容易發現前置條件，例如「服務費已收取」之前，必須先有「服務費已確認」",[113,493,495],{"id":494},"_7-問題與機會投票20-分鐘","7. 問題與機會、投票（20 分鐘）",[10,497,498,499,502],{},"最後請每個人寫下他認為最大的問題或機會，再用",[24,500,501],{},"箭頭投票","：每人兩票，畫在他認為最該優先處理的熱點或事件上。",[10,504,505],{},"票數最多的地方，就是接下來要用 Process Modeling 深入的流程。",[113,507,508],{"id":508},"收尾",[124,510,511,517,523],{},[127,512,513,516],{},[24,514,515],{},"拍照","：整面牆分段拍清楚，最好有人負責整理成數位版",[127,518,519,522],{},[24,520,521],{},"整理熱點清單","：每個熱點寫下要問誰、誰負責追",[127,524,525,528],{},[24,526,527],{},"說明下一步","：讓參與者知道這場的結果會怎麼被使用，下次才找得到人",[29,530,532],{"id":531},"process-modeling把一個流程拆清楚","Process Modeling：把一個流程拆清楚",[10,534,535],{},"Big Picture 投票選出「斡旋」這段後，找相關的人再跑一場 Process Modeling。這時要用上完整的語法，規則很簡單：",[537,538,539,545,551],"ol",{},[127,540,541,544],{},[24,542,543],{},"每個事件前面都有原因","：可能是某個角色發出的命令，也可能是一條政策",[127,546,547,550],{},[24,548,549],{},"每個命令前面都有角色或政策","，角色在發出命令前，通常需要看某個讀取模型",[127,552,553],{},[24,554,555],{},"每個事件後面接政策、讀取模型，或是流程結束",[10,557,558],{},"照著這個語法串下去，就會被迫回答很多 Big Picture 時跳過的問題：",[124,560,561,564,567,570],{},[127,562,563],{},"買方提出斡旋時，需要看到什麼資訊？（讀取模型：物件資訊、目前是否已經有人斡旋）",[127,565,566],{},"「斡旋已提出」之後，誰會知道？怎麼知道？（政策：通知屋主的經紀人）",[127,568,569],{},"斡旋期限到了，誰來處理？（政策：每當斡旋到期，就把斡旋標記為過期、退還斡旋金）",[127,571,572],{},"屋主同時收到兩組斡旋時，規則是什麼？（熱點：先到先處理，還是屋主自己選？）",[10,574,575],{},"Process Modeling 的產出很接近需求規格：命令就是功能，事件就是功能完成的結果，政策就是要自動化或要人工處理的規則，熱點就是還沒定案的問題。",[29,577,579],{"id":578},"software-design再往下一層","Software Design：再往下一層",[10,581,582,583,586,587,589],{},"如果團隊要開始寫程式，可以再跑一場 Software Design：把相關的命令和事件",[24,584,585],{},"圍繞著聚合","重新整理，問每個聚合要守住哪些規則。例如「斡旋已提出」、「斡旋已接受」、「斡旋已過期」都圍繞著「斡旋」這個聚合，「物件已上架」、「物件已改價」則屬於「物件」聚合。這部分可以參考 ",[13,588,16],{"href":15}," 裡的聚合設計原則。",[29,591,592],{"id":592},"主持人的技巧",[124,594,595,601,607,613,619,625],{},[127,596,597,600],{},[24,598,599],{},"控制時間，不控制內容","：每個階段都有時間盒，到了就進下一步。內容由參與者決定",[127,602,603,606],{},[24,604,605],{},"事件要用業務語言","：看到「訂單資料已更新」，問「業務上發生了什麼事？」",[127,608,609,612],{},[24,610,611],{},"衝突先貼熱點","：不要讓兩個人在牆前吵十分鐘，其他人站著等",[127,614,615,618],{},[24,616,617],{},"注意沒說話的人","：資淺的人常常最清楚實際狀況，但不敢在主管面前說。主持人可以直接問他們負責的那段",[127,620,621,624],{},[24,622,623],{},"不要讓開發人員主導","：開發人員容易把討論帶到「資料表怎麼設計」，Big Picture 階段先專注在業務",[127,626,627,630],{},[24,628,629],{},"事前和關鍵人物溝通","：如果主管會參加，事前說明這不是報告會，是一起探索，請他多聽少講",[29,632,633],{"id":633},"常見的失敗",[36,635,636,649],{},[39,637,638],{},[42,639,640,643,646],{},[45,641,642],{},"狀況",[45,644,645],{},"原因",[45,647,648],{},"改善",[58,650,651,662,673,684,695],{},[42,652,653,656,659],{},[63,654,655],{},"牆上都是「點擊按鈕」、「呼叫 API」",[63,657,658],{},"參與者以系統操作的角度思考",[63,660,661],{},"開場用業務事件示範，過程中隨時提醒",[42,663,664,667,670],{},[63,665,666],{},"只有兩三個人在貼",[63,668,669],{},"坐著開會、主管在場、沒有點名",[63,671,672],{},"移開椅子，主持人主動邀請每個部門",[42,674,675,678,681],{},[63,676,677],{},"吵了一小時沒有結論",[63,679,680],{},"想在當下解決所有分歧",[63,682,683],{},"衝突貼熱點，會後再找對的人解決",[42,685,686,689,692],{},[63,687,688],{},"貼完就沒有下文",[63,690,691],{},"沒有整理產出、沒有指定負責人",[63,693,694],{},"收尾時整理熱點清單與下一步",[42,696,697,700,703],{},[63,698,699],{},"範圍太大，一天貼不完",[63,701,702],{},"開場沒有定義起點和終點",[63,704,705],{},"先跑 Big Picture，細節留給 Process Modeling",[29,707,708],{"id":708},"一句話總結",[10,710,711],{},"Event Storming 的關鍵在準備與主持：找齊真正做事的人、準備夠長的牆和站著的空間，Big Picture 先讓每個人各自貼出過去式的領域事件，再一起整理時間軸、找出關鍵事件與邊界、補上人與系統、隨時標出熱點，最後走一遍並投票選出最該處理的問題；選出的流程再用 Process Modeling 的「角色、命令、聚合、事件、政策、讀取模型」語法拆清楚。",{"title":713,"searchDepth":714,"depth":714,"links":715},"",2,[716,717,722,725,736,737,738,739,740],{"id":31,"depth":714,"text":31},{"id":111,"depth":714,"text":111,"children":718},[719,721],{"id":115,"depth":720,"text":115},3,{"id":156,"depth":720,"text":156},{"id":194,"depth":714,"text":194,"children":723},[724],{"id":320,"depth":720,"text":320},{"id":346,"depth":714,"text":347,"children":726},[727,728,729,730,731,732,733,734,735],{"id":356,"depth":720,"text":357},{"id":363,"depth":720,"text":364},{"id":391,"depth":720,"text":392},{"id":428,"depth":720,"text":429},{"id":451,"depth":720,"text":452},{"id":465,"depth":720,"text":466},{"id":476,"depth":720,"text":477},{"id":494,"depth":720,"text":495},{"id":508,"depth":720,"text":508},{"id":531,"depth":714,"text":532},{"id":578,"depth":714,"text":579},{"id":592,"depth":714,"text":592},{"id":633,"depth":714,"text":633},{"id":708,"depth":714,"text":708},"2024-09-24","DDD 概論 簡單介紹過 Event Storming，Domain Storytelling 那篇也比較過兩者的差別。這段時間實際主持了幾場，發現光知道「橘色是事件、藍色是命令」遠遠不夠，一場 Event Storming 成不成功，八成取決於準備和主持。這篇把流程完整整理一次。",null,"md",{},true,"\u002Farticles\u002Fevent-storming-workshop",{"title":5,"description":742},"articles\u002Fevent-storming-workshop",[751,752,753,754,755],"DDD","領域驅動設計","Event Storming","需求分析","團隊協作","SUbue8-enCXyQs1KxPIBWKcFPL-SHNwo8RMBleGYeSI",1792959150340]