Architecture Decision RecordAWS 架构决策记录流程
架构决策记录（ADR）是一份文件，记录团队对伊拉打算搭个软件架构里向一个重要环节做个选择。每份 ADR 讲清爽迭个架构决策、决策个背景搭后果。ADR 有状态，所以会跟牢一个生命周期。要看 ADR 个例子，请参考附录。
ADR 流程会产出一批架构决策记录，迭批记录就组成决策日志。决策日志提供项目背景，还有详细个实施搭设计信息。项目成员会快速翻一遍每份 ADR 个标题，了解项目背景个大概；也会细看 ADR，深入了解项目个实施搭设计选择。
团队一旦接受某份 ADR，伊就变成勿好改。要是有新个认识需要做另外一个决策，团队就提一份新个 ADR。新 ADR 被接受之后，就取代之前搿份 ADR。
ADR 流程个范围
项目成员应该对每个影响软件项目或者产品、而且对架构有重大意义个决策建 ADR，包括下底各项（Richards 搭 Ford 2020）：
结构（比方微服务迭类模式）
非功能性需求（安全、高可用性搭容错能力）
依赖关系（组件之间个耦合）
接口（API 搭已经公布个合约）
构建技术（库、框架、工具搭流程）
功能性搭非功能性需求，是 ADR 流程最常见个输入。
ADR 个内容
团队发现需要一份 ADR 个辰光，会由一位团队成员根据全项目通用个模板开始写。（模板例子请看 ADR 个 GitHub 组织。）模板让建 ADR 变得简单，也保证 ADR 收齐所有相关信息。每份 ADR 起码应该定义决策个背景、决策本身，还有迭个决策对项目搭伊个交付成果个后果。（迭眼部分个例子请参考附录。）ADR 结构里向最有力量个一点，是伊聚焦辣决策个原因，而弗是团队哪能实施。晓得团队为啥做迭个决策，其他团队成员就更加容易接受；也可以避免呒没参与决策过程个其他架构师以后推翻迭个决策。
ADR 采用流程
每位团队成员侪可以建 ADR，勿过团队应该定一个 ADR 所有权个定义。每位当 ADR 所有者个作者，应该积极维护搭传达 ADR 个内容。为了讲清爽所有权，迭份指南辣下底个章节里向拿 ADR 作者叫做 ADR 所有者。其他团队成员随时侪好对 ADR 出力。要是 ADR 辣团队接受之前内容有变化，所有者应该批准迭眼更改。
团队确定一个架构决策搭伊个所有者之后，ADR 所有者辣流程开始个辰光，拿 ADR 以建议中（Proposed）状态提供出来。处辣建议中状态个 ADR 已经可以评审哉。
接下来 ADR 所有者发起 ADR 个评审流程。评审流程个目标，是决定团队接受 ADR、认为需要返工，还是否决 ADR。项目团队（包括所有者）来评审 ADR。评审会议应该一开始就留一段专门辰光来看 ADR，平均 10 到 15 分钟就够哉。迭段辰光里，每位团队成员看文件，加进意见搭问题，标出勿清爽个地方。评审阶段结束之后，ADR 所有者拿每条意见读出来，搭团队一道讨论。
要是团队发现有跟进事项可以改进 ADR，ADR 个状态维持建议中。ADR 所有者负责拟定行动，搭团队合作，拿每个行动指派给一个人。每位团队成员侪好出力，也好解决迭眼跟进事项。重新安排评审流程是 ADR 所有者个责任。
团队也可以决定否决 ADR。迭种情况下，ADR 所有者加一条否决个理由，防止以后对同样个话题再争论。所有者拿 ADR 状态改成已否决（Rejected）。
要是团队批准 ADR，所有者加上时间戳、版本搭利益相关者名单。然后拿状态更新成已接受（Accepted）。
ADR 搭伊拉组成个决策日志，代表团队做过个决策，也提供所有决策个历史。团队尽可能辣代码评审搭架构评审个辰光拿 ADR 当参考。除了做代码评审、设计任务搭实施任务，团队成员还应该查看 ADR，了解产品个战略决策。
好个做法是，每个软件更改侪应该经过同行评审，起码要一个人批准。代码评审个辰光，评审者可能发现更改违反一份或者几份 ADR。迭种情况下，评审者请代码更改个作者更新代码，同时分享 ADR 个链接。作者更新代码之后，经过同行评审者批准，合并到主代码库。
ADR 评审流程
ADR 一旦被接受或者被否决，团队应该拿伊当作勿好改个文件。要改现成个 ADR，必须新建一份 ADR，为新 ADR 建立评审流程，然后批准。要是团队批准新 ADR，所有者应该拿旧 ADR 个状态改成已取代（Superseded）。