事件風暴之後讓 AI 整理便利貼產出候選聚合
事件風暴（Event Storming）工作坊結束後，牆上留下大量領域事件、命令與聚合候選的便利貼。把這些便利貼交給 AI 整理成結構化清單，可以加速後續的建模工作。然而 AI 的角色僅限於提出候選，真正的聚合邊界與交易一致性判斷仍須由人決定。本文探討如何將工作坊產出餵給 AI、AI 最容易整理錯的地方，以及人機分工的實務建議。
🔖標籤 #ddd #ddd思考 #ai
[!AI] 本文摘要
事件風暴（Event Storming）工作坊結束後，牆上留下大量領域事件、命令與聚合候選的便利貼。把這些便利貼交給 AI 整理成結構化清單，可以加速後續的建模工作。然而 AI 的角色僅限於提出候選，真正的聚合邊界與交易一致性判斷仍須由人決定。本文探討如何將工作坊產出餵給 AI、AI 最容易整理錯的地方，以及人機分工的實務建議。
事件風暴（Event Storming）工作坊結束時，牆上或數位白板上通常會留下大量便利貼。這些便利貼涵蓋領域事件、命令、聚合、政策與參與者等不同構造類型，顏色各異且數量龐雜。與會者在過程中累積了豐富的討論成果，但工作坊一結束，往往面臨一個現實問題：如何把這些非結構化的便利貼轉換成可供開發團隊使用的領域模型文件。
傳統做法是找一個人手動謄寫、分類、歸納，再產出一份文件或模型草圖。這個過程耗時且容易遺漏細節。近年來大型語言模型的出現，讓我們多了一個選擇：把工作坊的產出餵給 AI，讓它整理成結構化清單，再由人來檢視與修正。這種做法的關鍵在於分工——AI 負責加速整理與分類，人負責判斷邊界與一致性。
事件風暴的產出結構
在討論 AI 如何介入之前，我們需要先釐清事件風暴的產出結構。Qlerify 在 What are Aggregates in Event Storming? 一文中說明，事件風暴是一種協作式的工作坊方法，用來快速探索與建模複雜的業務領域。過程中參與者會用不同顏色的便利貼標記不同的構造類型。
Calebe Santos 在 From Good to Excellent in DDD: Event-Storming as the Modeling Strategy to Create Domain-Driven Design - 9/10 一文中描述工作坊進行方式時指出，先標記橘色的領域事件，再往回找出藍色的命令，接著探索黃色的聚合與紫色的政策，並加入粉紅色的參與者與灰色/綠色的外部系統。他在文中也列出這些元素的意義：領域事件代表重要的業務發生；命令捕捉行動背後的意圖；聚合封裝領域邏輯並確保規則被執行；政策或流程反映對事件的業務反應並可能觸發新的命令；參與者代表發起行動的使用者或系統；外部系統與邊界則用灰色或綠色標示。
這些顏色編碼的便利貼在工作坊現場提供了視覺化的清晰度，但一旦工作坊結束，它們就只是一堆文字內容。要把它們轉換成可用的領域模型，需要進行有系統的整理與歸納。
讓 AI 整理便利貼
把工作坊的便利貼交給 AI 整理，第一步是確保輸入資料的完整性。你可以把數位白板上的便利貼內容匯出成文字，或者把實體便利貼拍照後做光學辨識，再將所有文字連同顏色標記一起提供給 AI。在提示詞中，要明確告訴 AI 每種顏色代表的構造類型，以及你期望的輸出格式。
以下是示意，展示如何用結構化的方式把便利貼內容提供給 AI：
[橘色-領域事件] OrderPlaced
[藍色-命令] PlaceOrder
[黃色-聚合候選] Order
[紫色-政策] 當 OrderPlaced 發生時，觸發後續命令
[粉紅色-參與者] 顧客
你可以要求 AI 做以下幾件事：按照命令與事件的對應關係分組、為每組命令與事件推論出可能的聚合候選、標註哪些便利貼之間存在政策觸發關係、以及初步識別可能的限界上下文邊界。Qlerify 在文中指出，聚合負責處理命令，當命令成功處理後，聚合會產生領域事件。這條因果鏈正是 AI 在分組時可以依循的核心邏輯。
AI 的輸出可以是一份表格或清單，列出每個聚合候選底下包含了哪些命令、事件，以及相關的政策與參與者。這份清單就是後續討論的起點，而不是最終答案。
AI 只提候選人決定邊界
讓 AI 整理便利貼的最大價值在於速度，但速度不能取代判斷。聚合的邊界涉及交易一致性、業務規則的封裝以及資料完整性，這些是需要人類根據業務理解來決定的。Qlerify 在文中說明，聚合定義了交易邊界，這意味著聚合內所有變更在聚合被視為完成之前必須一致。聚合也負責強制執行其包含的實體與值物件之間的一致性規則，確保不會出現不一致或部分的更新。
這些判斷需要對業務有深入理解。Stack Overflow 上有一則討論串 DDD Event storming alone，提問者詢問在獨自一人且同時是領域專家的情況下，是否適合使用事件風暴。回答者 Levi Ramsey 指出，事件風暴的核心是拆解系統中狀態如何改變、什麼觸發了特定的狀態改變，以及這些狀態改變如何對外部觀察者可見。但他也提醒，當你同時是領域專家且擁有大量內隱知識時，容易忽略「如果發生…會怎樣」這類問題，而有經驗的引導者在場可以幫助提出這些容易被忽略的提問。
這個觀點同樣適用於 AI 輔助整理的情境。AI 可以快速分組與推論，但它不會主動質疑「這兩個事件真的應該在同一個聚合內嗎」或「這個聚合是否太大，需要拆分」。這些問題需要人來思考。
- 候選清單的角色：AI 產出的聚合候選清單是討論的起點，每個候選都應該被視為待驗證的假設，而非已確認的結論。
在實務上，建議把 AI 產出的候選清單帶回團隊，逐一檢視每個聚合候選的邊界是否合理。檢視的重點包括：這個聚合內的所有變更是否需要在同一筆交易中完成？是否存在跨聚合的一致性需求？是否有聚合過大或過小的問題？這些問題的答案往往需要回到業務專家那裡確認。
AI 最容易整理錯的地方
AI 在整理事件風暴產出時，有幾個常見的錯誤模式。第一個是聚合邊界過大。AI 傾向於把語意上相關的命令與事件全部歸到同一個聚合底下，但聚合的大小應該取決於交易一致性邊界，而非語意相似度。Qlerify 在文中提到，聚合透過將相關的實體與值物件分組來降低領域的複雜度，但分組的依據是業務規則的強制執行範圍，不是單純的語意關聯。
第二個常見錯誤是混淆限界上下文與聚合的層級。限界上下文是較大的語意邊界，內部可以包含多個聚合。AI 在整理時可能會把不同限界上下文的便利貼混在一起，或者把應該是限界上下文層級的邊界直接當成聚合邊界。Stack Overflow 上 Kieran 在回應中指出，聚合是代表業務模型中實體與邏輯的物件，而限界上下文是依照通用語言將聚合分組，並由與其他共享資料但使用不同語言的上下文之間的依賴關係來界定邊界。以訂單聚合為例，它可能同時存在於產品銷售與產品履約兩個不同的限界上下文中。
第三個錯誤是忽略政策的觸發鏈。政策代表對事件的業務反應，可能觸發新的命令。AI 在整理時容易把政策當成獨立的便利貼處理，而沒有正確連結到它所觸發的命令與所反應的事件。Calebe Santos 在文中將政策描述為反映對事件的業務反應，可能觸發新的命令。如果政策連結遺失，整個流程的因果鏈就會斷裂，後續的聚合判斷也會受到影響。
- 政策連結的遺漏：AI 容易把政策便利貼當成孤立項目，而未正確連結到觸發事件與後續命令，導致流程因果鏈斷裂。
第四個錯誤是過度推論。AI 可能會在工作坊產出的便利貼之外，自行補充不存在的命令或事件。這些補充有時是合理的推論，有時則是幻覺。你需要逐一核對 AI 產出的每個項目是否都有對應的便利貼來源。
重點
事件風暴工作坊的價值在於協作過程中累積的共享理解，而 AI 的角色是加速把這份理解轉換成結構化清單。以下是實務上可以直接做的建議：
- 保留顏色標記：在把便利貼內容提供給 AI 時，務必保留每張便利貼的顏色與構造類型標記，讓 AI 能正確區分事件、命令、聚合、政策等不同元素。
- 要求 AI 標註推論：在提示詞中明確要求 AI 區分哪些是直接從便利貼整理的內容、哪些是它的推論，並對推論部分加上標記，方便後續人工檢視。
- 逐組驗證聚合邊界：把 AI 產出的每個聚合候選帶回團隊討論，確認交易一致性邊界是否合理，並檢查是否有聚合過大需要拆分的情況。
- 檢查政策的觸發鏈：確認每個政策都正確連結到觸發事件與後續命令，避免流程因果鏈斷裂。
- 不要跳過限界上下文層級：在確認聚合邊界之前，先確認限界上下文的邊界是否合理，因為聚合邊界的判斷依賴於限界上下文的語意範圍。
AI 能大幅縮短從便利貼到結構化清單的時間，但聚合邊界的最終決定權始終在人。把 AI 當成加速工具，把判斷留給理解業務的人，這才是事件風暴後續整理的正確分工。