📚 课程目录第3章识别领域事件（上）

3. 识别领域事件（上）：什么是领域事件、事件命名规范与提取方法

领域事件是事件风暴的核心产出物，也是微服务架构中服务间异步通信的“第一公民”。本节将定义领域事件的概念、命名规范，并演示如何从用户故事和业务流程中系统性地提取事件。

3.1 什么是领域事件

领域事件（Domain Event）是领域专家和开发团队共同关注的、在业务过程中发生的、具有业务意义的事实记录。它回答了一个核心问题：“在这个业务系统中，发生了什么值得记录的事情？”

  关键特征：
  已发生的事实：事件代表过去已经完成的操作或状态变更，不可撤销。
业务意义：只有对业务有影响、需要被其他部分感知或响应的变化才构成领域事件。
不可变性：事件一旦产生，其内容不应被修改；如需修正，应发布新的事件。
触发后续动作：事件通常会引发其他流程、规则或服务的响应。

在事件风暴工作坊中，领域事件通常使用橙色便签（物理或数字）表示，贴在时间轴的上方或核心位置。

3.2 事件命名规范：过去时态

领域事件的命名必须遵循“过去时态”原则，以明确表达事件已经发生。命名格式通常为：

【业务主体】+【过去式动词短语】

常见命名模式示例：

错误命名（现在时/将来时）	正确命名（过去时）	说明
订单创建	订单已创建	明确表示创建动作已完成
支付处理	支付已处理	强调支付流程已结束
库存扣减	库存已扣减	库存数量已变更
用户注册	用户已注册	注册流程已走完
退款申请	退款已申请	申请动作已提交

命名检查清单：

✅ 动词使用过去式（已创建、已支付、已取消、已发货）
✅ 名词使用业务术语（订单、支付、库存、用户）
✅ 事件名称能独立表达完整业务含义
❌ 避免模糊动词（处理、操作、更新）
❌ 避免技术细节（数据库更新、消息发送）

3.3 从用户故事中提取事件

用户故事（User Story）是提取领域事件的起点。每个用户故事通常包含多个业务步骤，每个步骤都可能产生一个或多个领域事件。

提取步骤：

拆解用户故事：将用户故事分解为“角色-动作-结果”的原子步骤。
标记状态变更：识别每个步骤中业务对象的状态变化。
转换为过去时事件：将状态变更用过去时态表达。

示例：用户故事“作为买家，我可以在购物车中提交订单，以便完成购买”

步骤	业务动作	状态变更	领域事件
1	买家点击“提交订单”	购物车 → 订单（待支付）	订单已创建
2	系统校验库存	库存预占	库存已预占
3	系统计算总价	订单金额确定	订单金额已计算
4	系统通知买家	订单状态更新	订单已提交待支付

3.4 从业务流程中提取事件

业务流程通常以泳道图、流程图或活动图的形式存在。提取事件时，关注跨角色、跨系统的关键节点。

提取方法：

识别决策点：每个“是/否”分支通常对应一个事件。
识别外部交互：与外部系统、第三方服务的每次交互都可能产生事件。
识别超时/异常：超时、失败、拒绝等异常路径也是重要事件来源。
识别时间触发：定时任务、到期处理等时间相关节点。

常见陷阱：

事件粒度太粗：一个事件包含多个业务含义，如“订单已处理”应拆分为“订单已支付”“订单已发货”等。
事件粒度太细：将技术操作（如“数据库已更新”）作为领域事件，缺乏业务语义。
遗漏补偿事件：只关注正常流程，忽略取消、退款、重试等补偿性事件。

3.5 领域事件提取流程（SVG）

下图展示了从用户故事和业务流程中提取领域事件的完整流程：

3.6 典型领域事件示例

以下是在电商、金融、物流等常见业务域中，经过规范命名后的领域事件示例：

业务域	用户故事/流程节点	领域事件
电商	买家提交订单	订单已创建
	支付网关回调成功	支付已成功
	仓库完成拣货	订单已发货
金融	用户发起转账	转账已发起
	风控系统审核通过	风控已通过
	账户余额不足	转账已失败
物流	快递员揽收包裹	包裹已揽收
	包裹到达中转站	包裹已到达中转站
	收件人签收	包裹已签收

3.7 事件提取实战：订单履约流程（SVG）

以下是一个完整的订单履约业务流程，标注了每个关键节点对应的领域事件：

3.8 本节小结

  核心要点回顾：
  领域事件是已发生的业务事实，使用过去时态命名。
从用户故事中提取事件：拆解步骤 → 识别状态变更 → 转换为过去时事件。
从业务流程中提取事件：关注决策点、外部交互、超时异常、时间触发。
注意事件粒度适中，包含补偿事件，避免技术细节。
领域事件是微服务间异步通信的基础，也是后续聚合和限界上下文划分的重要输入。