# Architecture Review 检查表

将其作为审查辅助，不要为了填表而制造发现。将每项标记为 supported、unclear、risk 或 not applicable，并引用证据。

## Scope 与 drivers

- 系统边界是否明确？
- 是否写明参与者、业务能力、非目标、约束和所有权？
- 驱动决策的质量场景是否可测量？
- 事实、假设和未知项是否分开？

## 边界与依赖

- 每个组件或模块是否拥有一致的职责？
- 数据和行为所有权是否明确？
- 接口是否小而稳定，并且独立于存储细节？
- 依赖方向是否有意设计且没有无法解释的循环？
- 受影响单元能否在所需边界上被测试、部署和修改？

## 数据与契约

- 每个重要数据是否只有一个权威所有者？
- 一致性、事务、顺序、重复、重放和幂等规则是否明确？
- 是否处理 schema 演进、保留、隐私和迁移？
- 必要的外部契约是否版本化或经过兼容性测试？

## 运行时与韧性

- 同步和异步路径是否清晰？
- 超时、重试、退避、熔断、队列和背压语义是否有意设计？
- 什么会一起失败？在依赖或实例故障期间什么仍可用？
- 是否定义恢复点、恢复时间和降级行为？
- 日志、指标、追踪、告警和负责人是否足以诊断设计？

## 安全与运维

- 信任边界、身份、授权、密钥和敏感数据流是否明确？
- 最小权限模型是否与建议边界兼容？
- 部署、扩缩容、发布、回滚、备份和灾难恢复是否可运维？
- 设计是否符合团队的支持和 on-call 能力？

## 迁移与决策质量

- 可行时迁移是否是渐进式的？
- 每一步是否有兼容计划、成功信号、回滚和清理条件？
- 是否使用相同标准比较了有意义的替代方案？
- 是否记录被拒绝的方案和接受的风险？
- 是否定义重新审视触发器和验证计划？