《后端架构设计·架构基础与边界》附录 C 架构评审清单

怎么用这份清单

这份清单不是评分表，也不是审批门槛。它的用途是：在一次架构评审前，快速判断“哪些问题有答案、哪些问题还没被问到”。

使用方法：

1. 评审前，主持人按九个部分逐项过一遍，标出“有材料”“口头说过”“完全没提”；
2. 评审时，只讨论“口头说过”和“完全没提”的项，避免在已经有材料的地方重复耗时；
3. 评审后，把未通过项转成行动项，写清负责人和关闭条件；
4. 下次评审，先检查上次行动项的关闭情况。

每项有三个状态：

清单不要求全部通过。它要求每个“不通过”都有明确的理由和后续动作。

一、问题与约束

二、业务边界

三、模块与依赖

四、接口与契约

五、数据与一致性

六、异步与幂等

七、安全与信任

八、部署与运维

九、演进与治理

十条常见失败模式

第一，方案很大，问题很小。评审花了三小时讲平台化，最后发现当前痛点是订单状态机没有约束。先确认问题，再谈方案。

第二，所有质量属性都是形容词。“高可用、低延迟、可扩展”没有数字，无法验收，也无法比较方案。

第三，边界画在组织图上。按现有团队分服务，而不是按业务能力和数据所有权划分，结果团队一变，系统就要重拆。

第四，把共享数据库当集成方式。两个服务读写同一张表，却声称“独立部署”；任何 schema 变更都会同时影响两边。

第五，用消息队列掩盖一致性问题。发消息不等于最终一致；没有对账、没有补偿、没有收敛期限，只是把不一致藏得更深。

第六，接口没有错误契约。调用方按错误文本分支，翻译一次就全坏；错误码不稳定，重试策略也无从设计。

第七，安全只在网关做。内部服务互相信任，一个被攻破的实例可以横向访问所有数据。

第八，发布没有回滚。代码能回滚，数据迁移不能回滚；上线前没想清楚兼容窗口。

第九，架构规则没有检查。依赖方向、模块边界、命名约定都写在文档里，CI 里一条都不跑。

第十，评审没有结论。会上每个人都说了意见，散会后没有行动项、没有负责人、没有关闭条件；三个月后同样的问题再开一次会。

评审记录模板

评审记录不需要很长，但必须能回答“谁、什么时候、基于什么材料、得出了什么结论”。

评审主题：
日期与参与角色：
输入材料：
  - 架构视图（版本/链接）：
  - ADR 列表：
  - 风险台账：
  - 压测或实验数据：

一、已确认的约束
  - 业务：
  - 技术：
  - 组织：

二、逐项结论
  | 议题 | 结论（接受/附条件/否决/待验证） | 理由 | 负责人 | 关闭条件 |

三、未采纳的反对意见
  - 意见：
  - 否决理由：
  - 重新评估触发条件：

四、行动项
  | 行动 | 负责人 | 截止时间 | 验收方式 |

五、遗留风险
  | 风险 | 等级 | 负责人 | 缓解措施 | 关闭条件 |

模板里最重要的是“未采纳的反对意见”和“关闭条件”。前者保留未来重新评估的线索，后者防止行动项永远停在“进行中”。

结论口径

评审结论建议只用四种，避免“基本同意”“原则上通过”这类无法执行的表述：

“附条件接受”必须写清条件是否可验证。比如“完成崩溃注入，证明提交后事件不丢”是可验证的；“再完善一下监控”不是。

按变更类型裁剪

九个部分不必每次全查。按变更类型裁剪，能让评审时间花在真正的风险上。

裁剪的原则是：变更直接触碰的部分必须查，间接影响的部分至少确认一次“是否受影响”。不能因为“这次只是小改动”就跳过安全或数据一致性——小改动也可能改错一个授权判断。

评审中的提问方式

清单是给主持人用的，不是给汇报人念的。提问方式决定了评审是走过场还是真的发现问题。

• 问“如果这个调用超时，用户看到什么”，而不是“你们考虑超时了吗”；
• 问“这条数据除了这个模块，还有谁会写”，而不是“数据所有权清楚吗”；
• 问“重复消息进来会发生什么”，而不是“幂等做了吗”；
• 问“上次类似改动出了什么问题”，而不是“风险大不大”；
• 问“这个决定什么时候需要重新评估”，而不是“以后怎么办”；
• 问“哪一条证据能证明它”，而不是“有把握吗”。

具体场景比抽象问题更容易得到真实答案。汇报人说“考虑过”时，追一句“那当时选了什么、否决了什么”，通常能立刻分辨是认真设计过，还是会上临时想的。

评审前的十分钟自检

如果时间只够做一件事，用下面八个问题快速扫一遍：

1. 这次要解决的业务问题是什么？有没有数字？
2. 最贵的三个变更是什么？当前架构让它们更贵还是更便宜？
3. 哪些状态迁移是合法的？规则写在哪？
4. 哪些数据只能有一个写 owner？现在有几个？
5. 一个请求穿过哪些模块？超时预算怎么分？
6. 重复请求、重复消息、重复回调，分别由谁去重？
7. 出故障时，第一眼从哪里看出卡在哪一步？
8. 如果明天要拆掉一个模块，第一步做什么？

八个问题里超过三个答不上来，说明方案还没到可以评审的程度。先把答案补上，再开会。

这份清单不负责什么

清单不判断方案是否优雅，也不替代架构师的经验。它能发现“没被问到的问题”，但发现不了“问到了却答错”的问题；答错只能靠实验、复盘和时间暴露。

清单也不保证所有条目都适用。小团队可以用它做自查，大组织可以按变更类型裁剪；两种用法都不需要把每一行都填满。

真正决定评审质量的，是参会者愿不愿意在“还没有答案”的地方停下来，而不是清单本身有多长。
清单能做的，只是把“停下来”的位置标出来。

小结

这份清单覆盖九个部分：问题与约束、业务边界、模块依赖、接口契约、数据一致性、异步幂等、安全信任、部署运维、演进治理。每项给出通过标准和红旗信号，目的是让评审聚焦在“没有答案的问题”上，而不是重复已有材料。

清单不能替代判断，也不能保证架构正确。它只能降低“重要问题没人问”的概率。真正的结论仍然要落在 ADR、风险台账和行动项上，并在下一次评审时检查关闭情况。