DDD 領域建模提示詞：事件風暴梳理領域事件、命令、聚合與業務規則
開始一個業務複雜的新模組（審批、結算、會員、履約）之前，想先把業務吃透再寫代碼時用：AI 主持一場文字版的事件風暴，從領域事件出發梳理命令、角色、規則和聚合，最後得到統一語言詞彙表和可以落地的領域模型。
通用大模型 對話模型通用
請你擔任事件風暴（Event Storming）工作坊的主持人，用文字方式帶我梳理一個業務領域。我是業務和技術的混合角色，你負責提問、整理和指出矛盾。 業務領域：[如企業報銷審批] 我已知的業務描述（流程、規則、例外情況）： [業務描述] 按以下環節推進，每個環節結束時停下來，等我確認或補充後再進入下一個： 環節一：領域事件。 按時間順序列出業務中發生的事情，用「名詞 + 過去式動詞」命名，例如「報銷單已提交」「審批已駁回」。特別追問異常和例外：撤回、超時、金額修改、重複提交、審批人不在時怎麼辦。 環節二：命令與角色。 為每個事件找出觸發它的命令（誰、做了什麼操作）或者觸發它的規則與時間（如「每月 1 日自動關閉」）。 環節三：業務規則。 找出命令執行前必須滿足的條件，例如「超過 5000 元必須由部門經理審批」。把它們寫成可以檢驗的語句，標出我沒說清楚的地方。 環節四：聚合。 把總是需要一起保持一致的數據和規則歸為一個聚合，說明聚合根是誰、它保護了哪些不變量、聚合之間通過什麼標識引用。 環節五：產出。 - 統一語言詞彙表：術語 | 含義 | 不要混用的近義詞； - 領域模型：聚合、實體、值對象、領域事件的清單，以及用 Mermaid 畫出的類圖或狀態圖； - 待澄清問題清單，可以拿去問業務方。 過程中請主動挑戰我的描述：發現前後矛盾、規則衝突或者「這裏其實是兩個概念」的情況時，直接指出來。
高亮處換成你自己的內容：[如企業報銷審批]、[業務描述]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[業務描述] 可以很粗糙，甚至只是幾句話。事件風暴的價值就在於通過提問把隱藏的規則挖出來。最好在環節一就把業務方拉進對話，或者把他們的回答原樣貼給 AI。
常見坑：
- 一上來就討論表結構和類設計，繞過了業務梳理。這條提示詞刻意從「發生了什麼事」開始，因為事件是業務人員最容易說清楚的東西。
- 同一個詞在不同場景含義不同卻混用（比如「客戶」既指下單人又指付款公司），這是後期最多 Bug 的根源。詞彙表一定要做。
- 聚合劃得太大，一個聚合包含了整個業務，導致並發衝突和性能問題。聚合應該只包含必須同時保持一致的部分。
追問技巧：模型出來後追問「用三個真實的業務案例（包括一個例外情況）走一遍這個模型，看是否每一步都有對應的命令和事件」。
示例輸出
示例，僅供參考（環節一節選：企業報銷審批）
| 順序 | 領域事件 | 追問 |
|---|---|---|
| 1 | 報銷單已創建 | 草稿是否需要儲存？ |
| 2 | 報銷單已提交 | 提交後還能修改金額嗎？ |
| 3 | 審批已通過 / 審批已駁回 | 駁回後是重新提交還是新建一張單？ |
| 4 | 審批已超時 | 超過幾天算超時？超時後自動通過還是轉交？ |
| 5 | 款項已支付 | 支付失敗時會產生什麼事件？ |
發現的矛盾：你提到「提交後不能修改」，又提到「財務可以調整金額」——這裏是否是兩個不同的操作（員工修改、財務核減）？
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～