本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# ADR 流程
架构决策记录（ADR）是一份文档，其中描述了团队针对他们计划构建的软件架构的重要方面所做的选择。每个 ADR 都描述了架构决策、其背景及其后果。 ADRs 有状态，因此遵循生命周期。有关 ADR 的示例，请参阅[附录](appendix.md)。
ADR 流程会输出架构决策记录的集合。该集合创建了决策日志。决策日志提供了项目上下文以及详细的实施和设计信息。项目成员可以浏览每个 ADR 的标题，了解项目上下文。他们阅读 ADRs 以深入了解项目实施和设计选择。
团队接受 ADR 后，该 ADR 就不可更改。如果新的见解需要不同的决策，团队会提出新的 ADR。团队接受新的 ADR 后，它将取代之前的 ADR。
## ADR 流程的范围
项目成员应为影响软件项目或产品的每个重要架构决策创建 ADR，包括以下内容（[Richards 和 Ford 2020](resources.md)）：
+ 结构（微服务等模式）
+ 非功能需求（安全性、高可用性和容错性）
+ 依赖关系（组件耦合）
+ 接口（APIs 和已发布的合同）
+ 构造技术（库、框架、工具和流程）
功能性和非功能性需求是 ADR 流程中最常见的输入。
## ADR 内容
当团队确定需要 ADR 时，团队成员就会开始根据项目范围的模板编写 ADR。（有关示例模板，请参阅 [ADR GitHub 组织](https://adr.github.io/)。） 该模板简化了 ADR 的创建，并确保 ADR 捕获所有相关信息。至少，每个 ADR 应定义决策的上下文、决策本身以及决策对项目及其可交付成果的影响。（有关这些部分的示例，请参阅[附录](appendix.md)。） ADR 结构最强大的方面之一是，它关注决策的原因，而不是团队如何实施决策。了解团队做出决策的原因可以使其他团队成员更容易采纳该决策，并防止其他未参与决策过程的架构师将来推翻该决策。
## ADR 采用流程
每个团队成员都可以创建 ADR，但团队应确定 ADR 的所有权定义。作为 ADR 所有者的每位作者都应积极维护和传播 ADR 内容。为了澄清这种所有权，本指南在以下部分中将 ADR 作者称为 *ADR 所有者*。其他团队成员也可以随时参与 ADR。如果 ADR 的内容在团队接受 ADR 之前发生更改，所有者应批准这些更改。
下图说明了 ADR 的创建、所有权和采用流程。
在团队确定架构决策及其所有者之后，ADR 所有者在流程开始时提供处于 “已**提议**” 状态的 ADR。 ADRs 处于 “已**建议**” 状态已准备就绪，可供审查。
然后，ADR 所有者启动 ADR 的审查流程。ADR 审查流程的目标是决定团队是接受 ADR、确定需要返工还是拒绝 ADR。包括所有者在内的项目团队负责审查 ADR。审查会议开始时，应安排专门的时间阅读 ADR。平均来说，10 到 15 分钟应该足够。在此期间，每位团队成员都要阅读文件，添加注释和问题，标出不明确的主题。审查阶段结束后，ADR 所有者会宣读并与团队讨论每条注释。
如果团队找到改进 ADR 的行动点，则 ADR 将保持**已提议**状态。ADR 所有者制定行动，并与团队合作，为每个行动添加一名受让人。每个团队成员都可以提出和解决行动点。ADR 所有者负责重新安排审查流程。
团队也可以拒绝 ADR。在这种情况下，ADR 所有者会添加拒绝的理由，以防止将来就同一主题进行讨论。所有者将 ADR 状态更改为**已拒绝**。
如果团队批准 ADR，所有者将添加时间戳、版本和利益相关者列表。然后，所有者将状态更新为**已接受**。
ADRs 他们创建的决策日志代表了团队做出的决策，并提供了所有决策的历史记录。团队在进行代码和架构审查时尽可能使用 ADRs 作为参考。除了执行代码审查、设计任务和实施任务外，团队成员还应就产品的战略决策 ADRs 进行咨询。
下图显示了应用 ADR 来验证软件组件的更改是否符合约定决策的过程。
最佳做法是，每个软件更改都应经过同行审查，并且至少需要一次批准。在代码审查期间，代码审阅者可能会发现违反一项或多 ADRs项的更改。在这种情况下，审核人员要求代码更改的作者更新代码，共享指向 ADR 的链接。当作者更新代码时，需要经过同行审核人员的批准并合并到主代码库中。
## ADR 审查流程
在团队接受或拒绝之后，团队应 ADRs 将其视为不可变的文档。对现有 ADR 的更改需要创建新的 ADR、建立新 ADR 的审查流程和批准 ADR。如果团队批准了新的 ADR，所有者应将旧 ADR 的状态更改为**已取代**。下图说明了更新流程。
