第3章 边界识别技术：事件风暴法、领域叙事法、用例分析

解决方案边界的准确性直接决定了架构设计的质量。在复杂业务域中，边界识别并非一次性的分析活动，而是通过多种技术交叉验证、逐步收敛的过程。本章深入讲解三种业界主流的边界识别技术——事件风暴法、领域叙事法和用例分析，从操作步骤、输入输出物、协同流程到异常处理给出完整的方法论框架。

3.1 边界识别技术概述

三种技术分别从不同视角切入问题域，产出互补的边界视图：

• 事件风暴法：以业务事件为驱动，通过时间轴上的事件流识别聚合与限界上下文，适合发现业务边界。
• 领域叙事法：以角色故事为载体，通过叙述工作场景提取实体与关系，适合勾勒领域边界。
• 用例分析：以用户目标为核心，通过系统交互分解功能范围，适合界定功能边界。

3.2 事件风暴法（Event Storming）

3.2.1 核心概念与适用场景

事件风暴是由Alberto Brandolini提出的协作建模技术，通过业务事件的时序排列，迫使领域专家和开发团队共同暴露业务规则与聚合边界。适用于以下场景：

• 全新领域或遗留系统逆向建模
• 需要快速识别限界上下文的大型项目
• 跨团队协作时统一业务语言

3.2.2 操作步骤

1. 准备事件空间：在长幅墙纸或白板上绘制时间轴，从左到右代表业务时间流。
2. 发散识别事件：使用橙色便签记录所有业务事件（过去时态动词），如「订单已提交」「库存已扣减」。
3. 归并与排序：按时间顺序排列事件，合并重复事件，发现缺失环节。
4. 标记命令与角色：使用蓝色便签标记触发事件的命令，使用黄色小标签标记执行角色。
5. 识别聚合与边界：围绕内聚性事件组划出聚合（红色边框），聚合间的自然断点即为限界上下文候选。

3.2.3 输入输出物

3.2.4 事件标记示例

在事件风暴工作坊中，便签使用以下颜色约定：

【橙色便签】业务事件（过去时态）
        例：「订单已创建」「付款已接收」「货物已发出」

【蓝色便签】命令（触发事件的动作）
        例：「提交订单」「确认付款」「安排发货」

【黄色小标签】执行角色
        例：「客户」「客服」「仓库管理员」

【红色粗框】聚合边界
        例：┌─ 订单聚合 ─────────────┐
            │  订单已创建 → 订单已确认 │
            └──────────────────────────┘

3.3 领域叙事法（Domain Storytelling）

3.3.1 核心概念与适用场景

领域叙事法由Stefan Hofer和Henning Schwentner提出，通过让领域专家讲述工作故事，以图形化叙事语言捕获实体、活动和数据流。适用于以下场景：

• 领域语言不一致或存在歧义
• 需要从实际操作视角发现隐含边界
• 作为事件风暴的补充，细化聚合内部结构

3.3.2 操作步骤

1. 选定叙事场景：请领域专家描述一个完整的业务场景，如「客户下单到收货的全过程」。
2. 实时绘制叙事图：使用图标和连线记录角色（火柴人）、活动（圆角矩形）、数据对象（文档图标）和流向（箭头）。
3. 标注时间顺序：在活动旁标注序号或时间戳，形成叙事路径。
4. 提取实体与关系：从叙事图中分离出核心实体，用关系线连接。
5. 划定领域边界：将强关联实体聚合成组，组间弱关联处即为领域边界。

3.3.3 输入输出物

3.3.4 叙事图记录格式

【叙事场景】客户取消订单
角色: 客户 👤 → 活动: 提交取消请求 📝
    → 数据对象: 取消申请单 📄
    → 活动: 审核取消条件 ✅
    → 角色: 客服 👤
    → 活动: 执行退款 💰
    → 数据对象: 退款记录 📄
    
【提取的实体】客户、取消申请单、退款记录、订单
【关系】客户 → 提交 → 取消申请单
        取消申请单 → 关联 → 订单
        退款记录 → 属于 → 客户

3.4 用例分析（Use Case Analysis）

3.4.1 核心概念与适用场景

用例分析源自Ivar Jacobson的面向对象方法，以参与者目标为锚点，通过主流程和扩展流程界定系统功能范围。适用于以下场景：

• 系统功能边界需要与用户角色一一对应
• 需要生成可测试的功能验收标准
• 在敏捷需求中需要快速划定迭代范围

3.4.2 操作步骤

1. 识别参与者：列出所有与系统交互的角色（人、系统、设备）。
2. 编写用例清单：每个参与者列出其业务目标，形成用例标题列表。
3. 细化主流程：为高优先级用例编写正常路径步骤。
4. 标注扩展流程：识别异常路径、分支条件和备选流。
5. 划定功能边界：将紧密相关的用例分组，组间依赖松散的边界即为系统模块边界。

3.4.3 输入输出物

3.4.4 用例规约模板

用例名称: 提交退货申请
参与者: 客户（主要），客服（次要）
前置条件: 客户已登录，订单状态为「已收货」
后置条件: 退货申请单状态为「待审核」

主流程:
  1. 客户选择已收货订单
  2. 系统显示订单详情
  3. 客户点击「申请退货」
  4. 系统创建退货申请单，状态置为「待审核」

扩展流程:
  2a. 订单超过退货期限
     2a1. 系统提示「已超过退货期限」，流程结束
  4a. 同一商品已申请过退货
     4a1. 系统提示「该商品已有退货申请」，流程结束

3.5 三种技术对比与选型权衡

3.6 协同流程与操作步骤

在实际项目中，三种技术并非孤立使用，而是形成递进式协同流程。以下是一套经过验证的协同操作步骤：

3.6.1 协同操作步骤

1. Step 1 — 事件风暴宏观定界：组织10-15人工作坊，产出限界上下文候选列表，确定业务域的大块分割。
2. Step 2 — 领域叙事细节验证：针对每个限界上下文，选取2-3个核心场景进行叙事访谈，验证实体归属是否合理。
3. Step 3 — 用例分析功能锁定：在确认的领域边界内，编写完整用例规约，细化功能范围和交互细节。
4. Step 4 — 边界冲突消解：召开三方合会，比对事件风暴的限界上下文、领域叙事的实体分组、用例分析的功能模块，标记不一致处并协商修正。
5. Step 5 — 边界冻结与交付：输出《解决方案边界定义书》，包含边界图、上下文映射、功能模块清单及设计约束。

3.6.2 输入输出物清单

3.7 异常处理与检查表

3.7.1 常见异常及处理策略

3.7.2 边界识别检查表

3.8 风险点与落地建议

3.8.1 主要风险点

• 风险R1 — 过度细化：在事件风暴中过早进入细节，导致边界碎片化。
  缓解：设定时间盒，第一轮只关注核心事件流。
• 风险R2 — 专家主导偏差：领域专家的个人经验覆盖了实际业务多样性。
  缓解：每个场景至少邀请2位不同背景的专家参与。
• 风险R3 — 用例范围蔓延：用例分析中不断新增「有用但不必要」的功能。
  缓解：严格按参与者目标驱动，所有用例必须对应具体业务目标。
• 风险R4 — 技术预判干扰：团队在边界识别时过早考虑技术实现（如数据库拆分）。
  缓解：在Step 5之前禁止讨论技术方案，只关注业务和领域逻辑。

3.8.2 落地建议

• 建议S1：首次使用事件风暴时，先进行1小时「迷你事件风暴」热身，选取一个子流程练习。
• 建议S2：领域叙事法的叙事图采用双人协作模式——一人讲述，一人绘制，避免信息丢失。
• 建议S3：用例分析采用模板驱动，团队统一用例规约模板（参见3.4.4），减少格式歧义。
• 建议S4：所有边界产出物必须经过三人复核（架构师 + 领域专家 + 测试代表），确保可理解性和可验证性。

3.9 验收标准

本章边界识别技术的应用成果，通过以下标准进行验收：

• AC1：事件风暴产出至少包含5个以上限界上下文候选，且每个上下文有明确的业务事件起止点。
• AC2：领域叙事法覆盖了所有核心业务场景（按业务优先级排序前80%场景），每个场景的实体关系图无歧义。
• AC3：用例分析产出的功能模块表与事件风暴的限界上下文、领域叙事的实体分组三方交叉比对，冲突点不超过3个且已消解。
• AC4：《解决方案边界定义书》已通过架构评审委员会审核，所有参与者签字确认。
• AC5：检查表（3.7.2）中所有项目均为「通过」状态，无一例外。