文章目录
- 说明
- 一 事件风暴理论知识
- 1.1 事件风暴的核心目标
- 1.2事件风暴的关键步骤
- 1.2.1 准备工作
- 1.2.2 核心流程
- 1.2.3 事件风暴的输出
- 1.3 事件风暴的优势
- 1.4 常见问题
- Q1：事件风暴适合所有项目吗？
- Q2：事件风暴后如何落地？
- Q3：在事件风暴里是否要列出所有的领域事件和命令？
- Q4：各个领域事件需要体现严格的时间顺序吗？
- Q5：每个步骤的颗粒度应该有多大？
- Q6：怎么保存和维护事件风暴的结果？
- Q7：怎么保存领域规则？
- 二 事件风暴实践
- 2.1 事件风暴的第一步：识别领域事件
- 2.2 识别“项目管理”流程的领域事件
- 2.3 识别其他流程的领域事件
- 2.4 关于领域事件的补充说明
- 2.5 事件风暴第二步：识别命令
- 2.6 事件风暴第三步：识别领域名词
- 三 深入理解事件风暴的作用
说明
- 本文学习自极客时间的《手把手教你落地DDD》，仅供学习和交流使用。
一 事件风暴理论知识
- 事件风暴（Event Storming）是DDD中一种高效的协作式建模方法，由 Alberto Brandolini 提出。它通过**领域事件（Domain Events）**作为核心，快速探索业务逻辑，识别聚合、限界上下文等关键元素。
1.1 事件风暴的核心目标
- 快速理解业务：通过事件流梳理业务流程。
- 发现领域模型：识别聚合、实体、值对象等。
- 划分限界上下文：明确系统边界和交互方式。
- 促进团队协作：业务专家、开发人员、架构师共同参与。
1.2事件风暴的关键步骤
1.2.1 准备工作
- 参与者：业务专家、开发人员、架构师等（建议 4-8 人）。
- 工具：白板、便利贴（不同颜色）、马克笔。
- 时间：通常需要 1-3 天的工作坊。
1.2.2 核心流程
- 识别领域事件（Domain Events）：表示业务中已发生的事实（过去时态）。示例：订单已创建（OrderCreated）、支付已受理（PaymentReceived）。
- 排序事件流：按时间顺序排列事件，形成业务流程的完整链路。
订单已创建 → 支付已受理 → 库存已扣减 → 物流已安排。 - 识别命令（Commands）：触发领域事件的动作（通常由用户或外部系统发起）。示例：
创建订单（CreateOrder） → 触发 订单已创建（OrderCreated） - 识别聚合（Aggregates）：管理一组相关对象的一致性边界（如
Order聚合根）。
- 规则：
- 每个命令必须由一个聚合处理。
- 每个事件必须由一个聚合发布。
- 示例:
Order聚合处理创建订单命令，发布OrderCreated事件。
- 识别角色（Actors）与外部系统
- 角色：谁发起了命令？（如用户、管理员、第三方服务）。
- 外部系统：哪些系统参与流程？（如支付网关、物流系统）。
- 划分限界上下文（Bounded Context）：将相关事件、聚合划分到独立的上下文中。
- 示例：
订单上下文：处理订单创建、支付。库存上下文：处理库存扣减。
- 识别策略（Policies）与规则
- 业务规则：如“支付超时自动取消订单”。
- 策略：通过领域事件触发后续动作（如
PaymentTimeout触发CancelOrder）。
1.2.3 事件风暴的输出
- 领域模型：明确的聚合、实体、值对象。
- 限界上下文：系统模块划分。
- 业务流程：事件流与命令的完整映射。
- 协作共识：团队对业务逻辑的统一理解。
1.3 事件风暴的优势
- 高效：快速梳理复杂业务，避免冗长文档。
- 可视化：通过便利贴直观展示逻辑。
- 协作友好：业务与技术人员共同参与。
- 适应变化：易于调整和迭代模型。
1.4 常见问题
Q1：事件风暴适合所有项目吗？
- 适合：业务复杂、需深度领域建模的系统（如金融、电商）。
- 不适合：简单 CRUD 或技术驱动型项目。
Q2：事件风暴后如何落地？
- 转换为 DDD 战术设计（实体、聚合、仓储等）。
- 结合 CQRS、事件溯源（Event Sourcing） 等模式实现。
Q3：在事件风暴里是否要列出所有的领域事件和命令？
- 列出所有领域事件和命令并没有原则上的错误，但这样做会让结果变得繁琐，反而让人抓不住重点。
- 建议：在事件风暴里只列出主要的、足以用于表达和交流领域知识的步骤，如签订合同、生效合同等等。而像修改合同和删除合同这样的步骤是显而易见的，在讨论过程中可以提一下，但不必列出。
Q4：各个领域事件需要体现严格的时间顺序吗？
- 只需要按照大致的顺序，贴出领域事件即可。如果要体现严格的时间顺序，需要用到更复杂的符号，例如条件判断，还有要画更多的连线，会使事件风暴变得非常繁琐。
Q5：每个步骤的颗粒度应该有多大？
-
事务完整性准则
- 当一组操作需要作为原子单元成功/失败时，应合并为单一领域事件
- 示例：合同签订包含「基本信息录入→明细填写→附件上传」三个步骤，若业务要求三者全部完成才算有效合同，则应聚合为「合同已签订」单个事件
-
业务价值导向
- 领域事件应反映对业务状态产生实质影响的关键节点
- 反例：合同草稿自动保存（无业务价值） vs 合同最终提交（触发法务审核）
-
事件消费意义检验
- 每个事件至少应有1个明确的下游消费者（如报表生成、风控系统等）
- 决策树：
- 合同签订案例
| 步骤 | 独立事件必要性 | 决策依据 | 最终方案 |
|---|---|---|---|
| 1. 录入基础信息 | ❌ | 中间状态无业务价值 | 合并到「合同已签订」 |
| 2. 填写付款条款 | ✔️ | 触发财务系统预审计 | 「合同条款已确定」 |
| 3. 上传签字扫描件 | ❌ | 仅作为合同完成的附属条件 | 合并到主事件 |
Q6：怎么保存和维护事件风暴的结果？
- 如果事件风暴的内容最终会反映到用户故事、用例、功能列表等产出物中，而这些产出物会进行维护，那我们就不必专门更新事件风暴的产出物了，只在需要的时候作为一种沟通工具，将电子化的结果作为一种中间产物保存就可以了。但是，如果你的团队并没有用户故事和用例等保存行为需求的方式，那么我建议你对事件风暴进行维护和更新。
- 除了绘图之外，事件风暴也可以用表格的形式来保存
| 业务流程 | 命令 | 领域事件 | 执行者 | 查询数据 | 领域对象 |
|---|---|---|---|---|---|
| 租户管理 | 添加租户 | 租户已添加 | 管理者 | – | – |
| 组织管理 | 添加开发中心 | 开发中心已添加 | 人事人员 | 企业 | – |
| 组织管理 | 添加开发组 | 开发组已添加 | 人事人员 | 开发中心 | – |
| 组织管理 | 添加直属部门 | 直属部门已添加 | 人事人员 | 企业 | – |
| 员工管理 | 添加员工 | 员工已添加 | 人事人员 | 所属部门 | – |
| 员工管理 | 转移员工 | 员工已转移部门 | 人事人员 | 目标部门 | – |
Q7：怎么保存领域规则？
- 领域规则是重要的领域知识，必须妥善保存。在事件风暴的过程里我们已经识别出了一些领域规则，在后续的领域建模阶段，可能还会识别出更多。
- 编辑一个领域规则表，把所有的领域规则都汇总在里面，然后再把领域规则表和领域模型放在一起，作为领域知识的重要组成部分。
| 规则编号 | 模块 | 规则描述 | 举例 | 影响的主要功能 |
|---|---|---|---|---|
| R001 | 项目管理 | 任一时刻，一个员工在各个项目上累计的预计投入工作量不能超过 100% | 小王在项目 A 上预计投入 60%，如果现在要把他同时分配到项目 B 上，那么项目 B 上的预计投入工作量不能超过 40% | 为项目分配员工 |
| R002 | 工时管理 | 员工只能在被分配的项目上报工时 | 小王被分配到项目 A 上，但没有分配到项目 B，则小王周一可以在项目 A 上报 4 小时，但不能在项目 B 上报工时 | 报工时 |
| R003 | 工时管理 | 一个员工一天累计工时不能超过 24 小时 | 小王被分配到项目 A 和 B 上，在周一，在 A 上报了 12 小时，在 B 上报了 13 小时，由于超过 24 小时所以不能通过 | 报工时 |
| R004 | 工时管理 | 员工只有在项目有效期内才能报工时 | 小王被分配到项目 A，项目 A 在 8 月 1 日结束，小王想在 8 月 5 日为项目 A 报工时则不能通过 | 报工时 |
| R005 | 工时管理 | 工时单位为小时，最小颗粒度为 0.5 小时 | 小王为项目 A 报 4.5 小时，可以通过，但报 4.6 小时，则不能通过 | 报工时 |
二 事件风暴实践
- 准备工作：准备场地、人员、工具，场地可以是较大的会议室或者有一面足够长的墙，人员包括技术人员（架构师、技术经理、测试人员）和业务人员（产品经理）。工具可以使用便利贴或其他电子形式的绘图工具。
2.1 事件风暴的第一步：识别领域事件
- 假设我是产品经理（具有较丰富的DDD经验），你是架构师。我开头和你讲了一遍需求，然后我们开始识别事件风暴的第一步：识别领域事件。
- 领域事件表示的是，业务流程中每个步骤引发的结果。事件风暴的作者认为，从结果入手来梳理需求，比从操作入手，更容易把业务想清楚。事件风暴中的“事件”两个字就来源于领域事件。
- 领域事件的命名，一般是完成时 + 被动语态。比如说，订单已提交。
2.2 识别“项目管理”流程的领域事件
- 首先进行项目管理流程的领域事件。我们各自按照自己的理解，把项目管理中发生的各个领域事件，分别梳理绘制，然后进行讨论，得出最终一致的结果。绘制结果如下：
- 首先，第一个区别，你写的是“客户已创建”，我写的是“客户已添加”。
- 你问我：“业务人员一般会说客户已创建还是客户已添加呢？”
- 我回答你：“一般是说客户已添加，因为从业务的角度，客户本来就是存在的 ，不需要创建，只是把客户资料添加到我们的系统而已”。
- 你表示同意。
- 然后，第二个区别，你写的是“签订合同”，我写的是“合同已签订”。
- “签订合同”是个动作，不是事件。所以达成一致后。
- 接着，第三个区别，你写的是“项目已创建”，我写的是“合同已生效”。我后面还有一步“立项”，应该和你的“项目已创建”是一回事，所以说明我比你多了一步“合同已生效”。
- 你又问：“合同签订以后不是马上就生效了吗，还要有一个额外的生效步骤吗？”
- 我解释说：“合同签订的时候未必马上生效，比如 1 月 1 日签了合同，但合同中可以约定，真正生效是在 2 月 1 日，所以需要一个单独的步骤让合同生效。”
- 然后你又问：“我写了项目已创建，但是你写的是已立项，你这种写法好像和其他的不太一致呀。”
- 我解释说：“虽然我们为领域事件命名的时候，常常用‘什么什么已什么什么’的形式，不过如果业务上已经有约定俗成的术语，我们就直接使用术语，这样更容易和业务沟通。现在业务觉得已立项是一个通用的术语，写成项目已创建反而显得生硬。”
- 在 DDD 中的各种命名，一般都优先使用约定俗成的业务术语。
- 目前讨论统一后的内容：
- 其次，第四个区别，我发现自己漏写了“项目已启动”。然后我们再比较了一下“项目已终止”和“项目已结束”两个说法，觉得“项目已结束”更符合业务术语。而“合同已结束”这一步，咱们俩是一样的。不过我在“项目已结束”前面还多了一个“员工已分配”。
- 于是你又问我：“刚才你讲需求的时候，好像是把员工分配作为一块单独的需求来讲的，不属于项目管理这个流程吧？”
- 我想了想，说：“员工分配背后的业务逻辑有点复杂，所以之前单独拿出来讲，其实员工分配是项目运作中的一个重要环节，放在项目管理中也没毛病。”
- 你对此表示认可。
- 我又补充了一点：“员工分配到项目的时候，要填入预计的投入工作量的百分比，一个人可以同时上多个项目，但预计的投入百分比总和不能超过 100%。这种逻辑一般叫业务规则，为了避免忘记，咱们也写上吧。”
-
再下一步，你多了一个“客户已终止”。
-
我解释说：“客户可以在系统中长期存在，以便不断挖掘商机，一般不必专门进行终止。理论上说，万一客户破产了，是应该终止，不过目前业务上还没有这个需求，这一点可以以后再考虑。”。 于是，我们把“客户已终止”拿掉了。
-
然后你又发现，我的流程中最后还多了一个“客户经理已更换”。
-
你有点惊讶地问：“可以更换客户经理吗？你刚才好像没说呀。”
-
我说：“可以更换，我刚才忘记说了。”
-
你紧跟着追问：“那么负责合同的销售人员，还有项目经理是不是也可以换呢？”
-
我说：“也可以。”
- 最后，我们把整个流程又仔细检查了一遍。又发现了一个遗漏的领域事件。员工分配到项目上以后，还可以下项目，所以应该有一个“员工已退出”事件。
2.3 识别其他流程的领域事件
- 用上述同样的方法，识别其他流程的领域事件。
2.4 关于领域事件的补充说明
- 不要把技术事件当成领域事件。领域事件一定要是领域专家所关注的，用的是业务术语。像数据库事务已回滚、缓存已命中之类的技术术语，不是领域事件，不在这个阶段讨论。
- 查询功能不算领域事件。领域事件应该是对某样事物产生了影响，并被记录的事情。一般是某个事物的创建、修改和删除。还有一种情况是向其他人或者系统发消息，例如“通知邮件已发送”也算领域事件，因为接收方可能会通过进一步处理来影响某些事物。而像“客户信息已查询”这些就不算领域事件，因为还没有对事物产生实际影响。不过，这并不代表查询功能不重要，查询功能也要以某种方式体现。
2.5 事件风暴第二步：识别命令
- 命令（command）是引发领域事件的操作，可以通过分析领域事件获得。除了识别出命令本身以外，我们通常还要识别出执行命令的角色，以及执行命令要查询的数据。比如说，对于“合同已签订”这个事件，对应的命令就是“签订合同”。这里，在水蓝色的便利贴上写出命令，然后贴在对应的领域事件上方。“签订合同”的操作者是“销售人员”。售人员术语上叫做“执行者”，英文是 actor。把执行者写在小一点的粉色便利贴上，贴在命令上方，如下图：
- 在执行“签订合同”操作时，执行者要先从系统里查出客户信息，才能和这个客户签订合同。这里，“客户”是一种“查询数据”。我们把查询数据写在小一点的绿色便利贴上，也贴在命令上方。
- 按照前面的方法一边讨论，一边识别出所有的命令。
2.6 事件风暴第三步：识别领域名词
- 领域名词是从命令、领域事件、执行者、查询数据里找到的名词性概念。例如，对于签订合同这个命令而言，受到影响的名词性概念是“合同”；类似地，对于合同已签订这个领域事件，是由于“合同”这个名词性概念的状态变化所导致的。
- 识别领域名词的操作步骤可以分成两小步。
- 第一步，挪动上一步的便利贴，把围绕同一个名词的命令、事件、执行者、查询数据摆在一起，分成好几“堆”，贴在墙上。
- 第二步，把领域名词写在大一点的黄色便利贴上，贴在每堆便利贴的中间。
- 所有领域名词识别结果
- 为项目分配员工”和“员工已分配”出现了两次，一次是关于“员工”的，另一次是关于“项目”的。因为这对命令和事件是关于两个名词的，所以抄写了两遍。关于项目的那次，在命令和事件后面加了一个 “2” ，就是同一个概念在图中出现了第二次的意思，这是我们画图时的一个常用技巧，其他有 “2” 的命令和事件也是同理。
三 深入理解事件风暴的作用
- 从整机视角来看，事件风暴是业务人员和技术人员一起协作，捕获行为需求、消化领域知识、形成统一语言的一种方法。
- 领域事件的作用：从代码实现的角度来看，领域事件一般会对应一段代码逻辑，这段逻辑可能会最终改变数据库中的数据。另外，在事件驱动的架构中，一个领域事件可能会表现为一个向外部发送的异步消息。
- 命令的作用：领域建模时，可以通过对命令的走查（walkthrough），细化和验证领域模型。在实现层面，一个命令可能对应前端的一个操作，例如按下按钮；对于后端而言，一个命令可能对应一个 API。
- 命令的执行者：在领域建模时，执行者可能本身就是一个领域对象，也可能是领域对象充当的角色，或者是权限管理中的一个角色。
查询功能不产生领域事件，因此也不会有相应的命令。那么如何保证查询功能不被遗漏呢？
- 实际上，每个查询数据对应着一个查询功能。查询数据是为某个命令服务。系统中可能还有一些单纯的查询功能，并不与某个特定的命令绑定。这些查询功能不会通过事件风暴识别出来，需要单独进行分析。
