为什么多数「架构方案」拆解是错的
评审时最常见的失败模式：需求一句话，方案三页架构图——微服务、消息队列、缓存全套上。问「这个模块解决哪个业务问题？」答不上来。
根因是从技术方案倒推需求，而不是从业务目标正推。正确顺序是先回答四个问题，再谈任何技术选型。
四步拆解法（每步都有产出物）
第 1 步：目标倒推——先把「要什么」翻译成「怎么算赢」
- 业务目标（要解决的问题、面向谁、什么时候要）
- 非目标（明确不做：本期只覆盖核心场景，其余砍掉或后置）
- 量化口径：核心指标（GMV / 转化 / 响应时间），验收时能不能用数据说话
产出物：一段 100 字以内的目标陈述 + 3 条以内的验收指标。
第 2 步：边界与角色——画出系统的「进出口」
- 参与者与角色：用户、运营、外部系统分别要什么
- 系统边界：哪些自己做，哪些调外部；接口与数据归属
- 关键约束：合规、安全、老系统兼容、数据不能出域等一票否决项
产出物：一张「角色 × 诉求」表 + 边界清单。这一步做扎实，后面不会出现「这个接口到底谁负责」的扯皮。
第 3 步：核心流程——先画「Happy Path」，再画分支
- 主线流程（用户完成一次核心价值的完整路径），用泳道图画出每个角色/系统的动作
- 分支与异常：超时、失败、重试、补偿、幂等——异常分支往往占真实工作量的 60%
- 异步机会：哪些步骤可以后置/异步，先标出来，不急着设计
产出物：主流程泳道图 + 异常分支清单。这一步是给评审人看的核心资产，比架构图重要。
第 4 步：模块与数据——从流程反推模块边界
- 按「变化的频率与原因」切模块（如订单域、库存域），而不是按「组织架构」或「技术栈」
- 数据归属：每个数据实体有唯一 owner；跨模块数据通过接口而非共享表
- 先出模块划分与数据流，再决定要不要微服务（见第 1 章：规模不到，微服务是负债）
产出物：模块图（含依赖方向）+ 核心数据实体清单。此时才进入技术方案写作（模板见文末链接）。
我踩过的坑
- 按页面拆模块：一个「用户中心」页面背后有账号、画像、积分三个不同变化节奏的域，硬捏成一个模块，三个月后重构。
- 跳过异常分支：方案里主线画得漂亮，评审被问「支付超时怎么办」当场卡壳——异常设计要跟主线一起进方案，不是事后补丁。
- 把「流程」和「状态」混为一谈：流程是时序，状态是结果。先定义清楚每个环节的最终状态（成功/失败/待补偿），代码才不会长成面条。
落地清单
- 100 字目标陈述 + 3 条验收指标
- 角色 × 诉求表 + 边界清单（含一票否决项）
- 主流程泳道图 + 异常分支清单
- 模块按「变化频率」划分，数据有唯一 owner
- 拆解产出物进技术方案，再进评审
延伸阅读：上章 · 技术选型方法论 · 下章 · 缓存体系设计实战 · 技术方案文档模板