Spotify 有多个团队使用架构决策记录（ADR）记录他们做出的各项决策。ADR 为 Spotify 带来了许多好处，包括改进新晋开发人员的入职管理，提升组织调整导致项目所有权移交的灵活性，改善团队之间关于最佳实践认知的一致性。
由于其天生具备不断演进的特性，所以架构决策记录技术经常在敏捷环境中使用。正如敏捷专家 Michael Nygard 所描述的那样：
架构决策记录包括可以帮助我们理解特定决策及其结果的上下文信息。此外，他们还可以记录没有做出的决策以及不这样决策的原因。
Spotify 工程师 Josef Blake 表示，决定何时编写 ADR 有时候并不容易，因为当一项决策对一个项目产生重大影响时，可能会存在多种理解方式。根据他的经验，至少在下述三种情况下编写 ADR。
首先，编写 ADR 来记录过去未记录的决策。这可以确保每个人都清楚地知道存在这项决策。
对于会对系统产生很大影响（例如会破坏 API）的更改，编写 ADR 是更改的最后一步。在这种情况下，Spotify 的工程师使用编写请求评议（RFC）的方法，促使所有利益相关者就一个共用的方法达成一致。一旦 RFC 过程完成，所商定的解决方案就会在 ADR 中记录。
不过，Blake 评论说，ADR 不应该只为具有重大影响的决策而编写。
在这种情况下编写的 ADR 可以使情况变得不那么复杂。
架构决策记录决不是一种新技术。轻量级决策记录在ThoughtWorks的技术雷达上已经存在了好几年。如果你有兴趣尝试，可以在这个存储库中查找其他信息和开箱即用的模板。
原文链接：
Architecture Decision Records At Spotify
