0.5 使用架构决策记录

作为开发人员、架构师，甚至是普通人，我们都曾处于这样的境地，想着过去的自己并发问：“他们当时到底在想什么？”如果你曾经驾车行驶在英国利兹和曼彻斯特之间的M62高速公路上，你可能会对这条高速公路的建设感到困惑。当驶上这条三车道的高速公路时，它开始与旁边的逆向车道相偏离，直到最后斯科特霍尔农场出现在车道之间，大约有15英亩（91.0545亩）农田。根据当地的传说，这块地的拥有者固执己见，拒绝搬迁或交出土地，所以工程师干脆在农场周围修建了高速公路[2]。50年后，一部纪录片揭示了真正的原因是土地下面存在地质断层，这意味着必须以这种方式修建高速公路。当人们猜测为什么某件事会以特定的方式进行时，你可以预料到各种传言、段子和批评都会出现。

在软件架构中，我们将面临许多需要考虑的约束条件，因此确保我们的决策被记录并可查阅是非常重要的。ADR（架构决策记录）有助于明确记录软件架构中的决策过程。

在项目的整个生命周期中，最难追踪的事物之一是某些决策背后的动机。新加入项目的人可能会对一些过去的决策感到困惑、迷惑、高兴或愤怒。

——ADR概念的创始人Michael Nygard

ADR有四个关键部分组成：状态、背景（context）、决策和影响。ADR在创建时处于建议状态，并通常会根据讨论结果被接受或拒绝。也有可能决策在以后被新的ADR取代。背景有助于设定场景并描述问题或决策的范围。尽管在ADR之前创建博客文章，然后从ADR中进行链接有助于团队跟踪工作进展，但背景并不局限于一篇博客文章或详细描述。决策清楚地阐明了你计划做什么以及如何做。所有决策在架构上都会造成影响或带来取舍，有时错误的决策可能导致高昂的代价。

在评审ADR时，重要的是看你是否同意ADR中的决策，或者是否有其他替代方案。事先未考虑到的替代方案可能导致ADR被拒绝。被拒绝的ADR具有很大的价值，大多数团队选择保留原始的ADR，以捕捉视角的变化。当ADR被展示给核心成员查看、评论并获得认可时，其发挥了最大功效。

我们经常被问到一个问题：团队在什么时候应该创建ADR？确保在ADR之前已经进行了讨论，并且记录是团队集体思考的结果，这是非常有用的。将ADR发布给其他团队可以获得外部的反馈机会。