#架构决策记录（ADR）

架构决策是软件项目中最容易被忽视、却影响最深远的工作。一个选型决策做对了，可以让团队未来三年少走很多弯路；一个选型决策做错了，会让团队付出远超预期的代价。

但更糟糕的情况是：团队做了决策，但没有记录决策过程。三年后，当新人问「为什么我们用 Kafka 而不是 RabbitMQ」时，没有人能回答——当初做决策的人要么离职了，要么不记得了。

架构决策记录（ADR）就是为了解决这个问题。

#什么是 ADR

ADR（Architecture Decision Record，架构决策记录）是一个简短的文档，记录了一个重要的架构决策：

• 决策的背景是什么
• 有哪些可选方案
• 为什么选择了这个方案
• 这个方案有什么代价

ADR 的核心价值不是文档本身，而是决策过程的可追溯性。当团队需要回顾决策、重审决策、或在新上下文下推翻决策时，ADR 提供了完整的上下文。

#ADR 的价值

很多团队不愿意写 ADR，觉得「这是额外的工作」。但 ADR 实际上节省的是未来的时间：

当新人入职时，ADR 让他们快速理解系统设计的来龙去脉，而不是面对一堆「魔法配置」。

当决策需要回顾时，ADR 提供了决策时的上下文，帮助团队判断这个决策是否仍然适用。

当决策被质疑时，ADR 证明了决策是经过深思熟虑的，不是随意的技术选择。

#本节内容

本节覆盖 ADR 的完整生命周期：

• ADR 编写规范 —— 什么样的 ADR 是有效的
• 权衡框架与决策树 —— 如何系统化地权衡方案
• 决策记录模板 —— 开箱即用的 ADR 模板
• 决策评审流程 —— 如何组织决策评审
• 经典架构决策案例 —— 从真实案例中学习决策逻辑