上下文与影响映射
在拍板前映射决策触及系统的哪些部分，让后果可见。
为什么
一个看着孤立的决策常常波及缓存、可观测性、部署和值班手册。上下文与影响映射迫使作者枚举决策触及的每个系统，在变成事故前暴露隐藏耦合。跳过这步的团队常常在采用三周后发现新队列搞坏了部署流水线，因为没人映射对 CI 配置的影响。映射画起来便宜，跳过代价昂贵。
何时使用
任何跨流程或团队边界的决策。耗时 15 分钟。仅对完全 contained 在一个模块、无外部接口变更的决策可跳过。
如何做
1. 列出决策直接改变的系统（如"数据存储"、"API 层"） 2. 对每个，向外追一跳：谁依赖它？它触及哪些配置？ 3. 画一个简单文本图：决策 → 系统 → 下游影响 4. 把每个影响标为 +（改善）、-（退化）、~（中性） 5. 把图作为 "Impact" 字段附到 ADR 6. 对每个 '-' 影响，加一行缓解措施，或在接受前升级处理
示例
决策：session 存储从 Redis 换到 DynamoDB
影响图：
决策 → session-store
→ API 层：+（不用管 Redis 连接池）
→ 部署：-（新 IAM 角色 + 建表步骤）
→ 值班：-（DynamoDB 限流比 Redis OOM 更难调试）
→ 成本：~（按量 DynamoDB ≈ 我们规模下的小 Redis）
→ 可观测性：-（现有 Redis 仪表盘失效；要新建）
缓解：切换前加 DynamoDB 限流告警 + 迁移手册。常见问题
- ⚠只映射顺利路径——退化（'-' 影响）正是致事故的，漏掉它们就失去了意义。
- ⚠画了图却不行动——没有缓解的 '-' 影响是已接受风险，应显式而非沉默。
最佳实践
- ✓映射控制在一屏——如果蔓延，说明决策太宽，应拆成多条 ADR。
- ✓专门和值班团队评审影响图；他们拥有 '-' 影响，必须同意。
- ✓采用 30 天后回看映射，验证预测影响是否与现实吻合——这校准未来的映射。