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