4、用例分析与场景驱动：编写用例文档，识别主成功场景与扩展场景，从用例到系统交互
好，咱们进入第四章。
前面几章我们聊了需求怎么来，怎么梳理。但说实话，光有需求列表还不够。你想想看，产品经理给你扔过来二十条需求，每条都写着「用户能下单」、「用户能退款」。然后呢？你怎么知道系统该先做什么，后做什么？
这时候，就需要用例分析登场了。
4.1 为什么非要用例不可？
我刚开始做架构那几年，也犯过傻。拿到需求直接画类图、画时序图，结果画到一半发现——哎？这个流程好像不对，用户到底是怎么操作的？
说白了，用例就是帮你把「用户想干什么」翻译成「系统该干什么」的桥梁。
我个人习惯，在写任何一行代码之前，先写用例文档。哪怕只是草稿，也能帮你避免至少一半的返工。
核心观点：用例不是需求文档，而是场景描述。它关注的是「用户与系统的交互过程」，而不是「系统有什么功能」。
4.2 用例文档长什么样？
一个标准的用例文档，通常包含这几个部分。我直接给你列出来：
| 要素 | 说明 | 示例（在线购物） |
|---|---|---|
| 用例名称 | 动词+名词，清晰表达目标 | 提交订单 |
| 参与者 | 谁在使用系统 | 注册用户 |
| 前置条件 | 开始前必须满足的状态 | 用户已登录，购物车非空 |
| 后置条件 | 成功结束后系统的状态 | 订单已创建，库存已扣减 |
| 主成功场景 | 最理想、最常用的流程 | 用户点击提交→系统校验→生成订单 |
| 扩展场景 | 异常、分支、可选流程 | 库存不足、支付超时、地址无效 |
嗯，这里要注意。很多人写用例只写主场景，觉得扩展场景「以后再说」。我曾经就吃过这个亏——项目上线第一天，用户输入了一个特殊字符，系统直接崩了。为什么？因为用例里没写「输入校验失败」这个扩展场景。
4.3 主成功场景：先走通那条阳光大道
主成功场景，也叫「快乐路径」。就是一切顺利的情况下，用户怎么完成目标。
举个例子，我们做一个「用户注册」功能。主成功场景可能是这样的：
- 用户输入手机号、密码、验证码
- 系统校验手机号格式
- 系统发送短信验证码
- 用户输入验证码
- 系统校验验证码正确
- 系统创建用户账号
- 系统返回注册成功
你看，这就是一条完整的交互链路。每一步都是「用户做了什么」→「系统响应了什么」。
我的小技巧：写主场景时，尽量控制在5-10步。太长了说明粒度太粗，可以拆成多个子用例。太短了说明你漏了细节。
4.4 扩展场景：那些「万一」的情况
扩展场景才是真正体现架构功底的地方。
你想想看，一个系统健不健壮，不是看它正常跑的时候有多快，而是看它出问题的时候怎么处理。
扩展场景通常包括：
- 异常流：比如网络断开、数据库超时、第三方服务挂了
- 分支流：比如用户选择了不同的支付方式、不同的配送地址
- 可选流：比如用户跳过了某个步骤、取消了操作
我建议你写扩展场景时，用「如果...那么...」的句式来思考。
比如上面那个注册的例子，扩展场景可以写：
- 如果手机号格式错误，系统提示「请输入正确的手机号」
- 如果验证码发送失败，系统提示「发送失败，请重试」
- 如果验证码输入错误超过3次，系统锁定该手机号15分钟
- 如果用户中途关闭页面，系统不做任何处理（会话超时后自动清理）
避坑指南：我曾经见过一个团队，写了30多个扩展场景，结果主场景只有5步。这其实走偏了。扩展场景不是越多越好，而是要覆盖「真正可能发生」的情况。那些概率极低、影响极小的场景，可以放到后续迭代里。
4.5 从用例到系统交互：画出来才清楚
用例文档写完了，下一步就是把它变成系统交互图。
我个人习惯用「系统时序图」或者「交互图」来呈现。说白了，就是把用例里的每一步，对应到系统的哪个模块、哪个接口。
举个例子，还是「提交订单」这个用例。主场景中的一步是「系统校验库存」。那对应的系统交互可能是：
用户点击「提交订单」
→ 前端调用 POST /api/orders
→ 订单服务调用 库存服务 checkStock(productId, quantity)
→ 库存服务返回 true/false
→ 如果 true，订单服务创建订单记录
→ 如果 false，返回「库存不足」你看，这样一画，架构的边界就清晰了。哪个服务负责什么，接口怎么设计，一目了然。
4.6 一个完整的用例文档示例
我直接给你一个我常用的模板，你拿去就能用：
| 用例名称 | 用户取消订单 |
|---|---|
| 参与者 | 已登录用户 |
| 前置条件 | 订单状态为「待支付」或「待发货」 |
| 后置条件 | 订单状态变为「已取消」，库存恢复 |
| 主成功场景 |
1. 用户进入订单详情页 2. 用户点击「取消订单」 3. 系统弹出确认对话框 4. 用户确认取消 5. 系统校验订单状态 6. 系统更新订单状态为「已取消」 7. 系统调用库存服务恢复库存 8. 系统返回取消成功 |
| 扩展场景 |
3a. 如果订单已发货，取消按钮置灰 5a. 如果订单状态异常（如已被系统取消），提示「订单状态异常，请联系客服」 7a. 如果库存服务恢复失败，记录异常日志，人工介入处理 |
关键提醒：用例文档不是写完了就完事的。它需要和产品、开发、测试一起评审。我见过太多因为「我以为」而导致的返工——你以为用户会这样操作，其实用户根本不按你的套路来。
4.7 小结：用例驱动，架构不迷路
好了，这一章的内容差不多就这些。
总结一下：
- 用例文档是需求到架构的翻译器
- 主成功场景走通核心流程
- 扩展场景覆盖异常和分支
- 从用例到系统交互，画出时序图，架构边界自然就出来了
下一章，我们会聊怎么把这些用例转化成真正的系统模块划分。说白了，就是怎么从「用户故事」变成「系统结构」。到时候见。