架构决策记录（Architectural Decision Record）

如果你所在的团队是一个快速迭代的团队，正在不断进行新的产品尝试，你可能没有时间事无巨细的记录完整的技术文档。

但是对于一些重大和基础的架构调整决策，可以通过一种叫 “架构决策记录（ADR，Architectural Decision Record）” 的方式记录下来 —— 尤其是当你是团队中技术负责人的时候。

ADR 可以记录在代码仓库，或者单独的 Notion、Jira 中。一般 ADR 中会包含如下内容

• 决策名称
• 决策背景
• 决策考虑的影响因素
• 决策方案（多个）
• 决策比较
• 决策结果
• 后续影响记录，以及可能的反思（经验教训）

为什么需要记录架构变更

• 知识共享：使团队成员（包括开发人员、测试人员、运维人员等）理解为什么做出特定的架构决策。
• 决策追溯：在项目的生命周期中，能够追溯架构决策的演变。随着业务需求的变化或者技术环境的改变，可能需要回顾之前的决策。比如，当系统性能出现问题时，通过查看 ADR 可以了解到当初在数据库选型（如选择关系型数据库 MySQL 而不是 NoSQL 数据库 MongoDB）方面的考虑因素，进而评估是否需要对该决策进行调整。因为并不是所有的人都能在半年甚至一年后，记清楚当初做某个决策的原因。
• 自我提升：回顾曾经的决策和所带来的结果，我们会从中学到成功或者失败的经验。

什么样的变更适合被定义为 “重大架构调整”

• Structure（软件结构）：
  • 对于微服务等模式，若对微服务架构进行大规模调整可视为重大架构调整。
    例如，将一个功能复杂的大型微服务