记录画图笔记
三、大公司实践：哪些必须画，哪些可以略？
| 图类型 | 是否必须 | 备注 |
|---|---|---|
| 系统架构图 | ✅ 必画 | 项目评审、开发同步都需要 |
| 时序图 | ✅ 必画 | 每个关键业务流程建议都画 |
| 部署图 | ✅ 必画 | 交付上线、运维对接不可少 |
| 数据库ER图 | ⚠️ 视情况 | 如果表少可以省略，但核心模块一定要画 |
| 功能流程图 | ⚠️ 视情况 | 产品需求阶段有产出即可，开发侧通常参考，不一定自己画 |
| 状态图、类图等 | ❌ 可选 | 通常用于复杂逻辑或多人协作时补充 |
不要所有功能都画图，而是聚焦以下内容：
- 核心流程（如登录、支付、下单、退款等）
- 系统间接口（微服务之间的调用）
- 重复变更或多人维护的模块
图和文档要并行更新，避免图过期。
图要版本化管理，推荐放在 Git 项目文档目录下（如 /docs/design/）
✅ 2. 流程图 / 泳道图 / 业务流程图
用途：展示一个完整业务流程的步骤、用户参与方、状态变化。
| 是否要做 | 场景 | 原因与建议 |
|---|---|---|
| ✅ 要做 | 涉及多个角色协作的流程（如 审核流、订单流、支付链路） | 有助于对齐需求，避免遗漏关键逻辑，开发测试理解统一 |
| ✅ 要做 | 复杂状态变化（如：订单状态、审批状态） | 泳道图可清晰展示不同用户或系统的操作边界 |
| ❌ 可以不做 | 单接口单操作场景，逻辑很简单（如“点击就执行”） | 这类流程写成文字+接口文档即可，画图反而啰嗦 |
| ❌ 可以不做 | 接口功能已经在时序图中完整表达了 | 如果时序图已涵盖流程，流程图可不画，避免重复工作 |
✅ 总结建议（给开发的实战建议）
| 图类型 | 什么项目要画 | 不画的替代方式 |
|---|---|---|
| 菜单图 / 模块结构图 | 做后台管理系统、SaaS | 简单系统可直接列接口文档或接口分组 |
| 流程图 / 泳道图 | 有复杂业务流程，涉及多个角色 | 简单逻辑用接口注释或文字流程描述代替 |
| 权限功能表格 | 权限体系明确、多角色系统 | 权限不复杂时写在 PRD 或模块描述里 |
泳道活动图，更侧重于表达谁做了什么事；而时序图，除了强调流程中交互的消息和顺序，还表达谁对谁做了什么事。
我的体会是，遇到强调消息传递、时间顺序的，用时序图；遇到流程比较复杂、分支比较多的，用活动图。