DDD 领域建模提示词：事件风暴梳理领域事件、命令、聚合与业务规则
开始一个业务复杂的新模块（审批、结算、会员、履约）之前，想先把业务吃透再写代码时用：AI 主持一场文字版的事件风暴，从领域事件出发梳理命令、角色、规则和聚合，最后得到统一语言词汇表和可以落地的领域模型。
通用大模型 对话模型通用
请你担任事件风暴（Event Storming）工作坊的主持人，用文字方式带我梳理一个业务领域。我是业务和技术的混合角色，你负责提问、整理和指出矛盾。 业务领域：[如企业报销审批] 我已知的业务描述（流程、规则、例外情况）： [业务描述] 按以下环节推进，每个环节结束时停下来，等我确认或补充后再进入下一个： 环节一：领域事件。 按时间顺序列出业务中发生的事情，用「名词 + 过去式动词」命名，例如「报销单已提交」「审批已驳回」。特别追问异常和例外：撤回、超时、金额修改、重复提交、审批人不在时怎么办。 环节二：命令与角色。 为每个事件找出触发它的命令（谁、做了什么操作）或者触发它的规则与时间（如「每月 1 日自动关闭」）。 环节三：业务规则。 找出命令执行前必须满足的条件，例如「超过 5000 元必须由部门经理审批」。把它们写成可以检验的语句，标出我没说清楚的地方。 环节四：聚合。 把总是需要一起保持一致的数据和规则归为一个聚合，说明聚合根是谁、它保护了哪些不变量、聚合之间通过什么标识引用。 环节五：产出。 - 统一语言词汇表：术语 | 含义 | 不要混用的近义词； - 领域模型：聚合、实体、值对象、领域事件的清单，以及用 Mermaid 画出的类图或状态图； - 待澄清问题清单，可以拿去问业务方。 过程中请主动挑战我的描述：发现前后矛盾、规则冲突或者「这里其实是两个概念」的情况时，直接指出来。
高亮处换成你自己的内容：[如企业报销审批]、[业务描述]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[业务描述] 可以很粗糙，甚至只是几句话。事件风暴的价值就在于通过提问把隐藏的规则挖出来。最好在环节一就把业务方拉进对话，或者把他们的回答原样贴给 AI。
常见坑：
- 一上来就讨论表结构和类设计，绕过了业务梳理。这条提示词刻意从「发生了什么事」开始，因为事件是业务人员最容易说清楚的东西。
- 同一个词在不同场景含义不同却混用（比如「客户」既指下单人又指付款公司），这是后期最多 Bug 的根源。词汇表一定要做。
- 聚合划得太大，一个聚合包含了整个业务，导致并发冲突和性能问题。聚合应该只包含必须同时保持一致的部分。
追问技巧：模型出来后追问「用三个真实的业务案例（包括一个例外情况）走一遍这个模型，看是否每一步都有对应的命令和事件」。
示例输出
示例，仅供参考（环节一节选：企业报销审批）
| 顺序 | 领域事件 | 追问 |
|---|---|---|
| 1 | 报销单已创建 | 草稿是否需要保存？ |
| 2 | 报销单已提交 | 提交后还能修改金额吗？ |
| 3 | 审批已通过 / 审批已驳回 | 驳回后是重新提交还是新建一张单？ |
| 4 | 审批已超时 | 超过几天算超时？超时后自动通过还是转交？ |
| 5 | 款项已支付 | 支付失败时会产生什么事件？ |
发现的矛盾：你提到「提交后不能修改」，又提到「财务可以调整金额」——这里是否是两个不同的操作（员工修改、财务核减）？
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～