本指南介绍了软件工程项目的架构决策记录 (ADR) 过程。ADR 支持团队协调，记录项目或产品的战略方向，并减少重复和耗时的决策工作。
在项目和产品开发期间，软件工程团队需要做出架构决策以实现其目标。这些决策可以是技术性的，例如决定使用命令查询职责分离 (CQRS) 模式，也可以是与流程相关的，例如决定使用 GitFlow 工作流来管理源代码。做出这些决定是一个耗时且困难的过程。团队必须证明、记录这些决定并将这些决定传达给相关的利益相关者。
在做出架构决策时，经常会出现三种主要的反模式：
- 因为害怕做出错误的选择，根本没有做出任何决定。
- 一个决定是在没有任何理由的情况下做出的，人们不明白为什么会做出这样的决定。这导致同一主题被多次讨论。
- 决策不会在架构决策存储库中捕获，因此团队成员会忘记或不知道已做出决策。
在产品或项目的开发过程中处理这些反模式特别重要。
以 ADR 的形式捕获导致决策的决策、背景和考虑因素，使当前和未来的利益相关者能够收集有关所做决策和每个决策背后的思考过程的信息。这减少了软件开发时间，并为未来的团队提供了更好的文档。
有针对性的业务成果
ADR 针对三个业务成果：
- 他们使当前和未来的团队成员保持一致。
- 他们为项目或产品设定了战略方向。
- 他们通过定义一个流程来正确记录和传达架构决策，从而避免决策反模式。
ADR 捕获决策的背景，以告知未来的利益相关者。ADR 集合提供了移交经验和参考文档。团队或项目成员使用 ADR 集合进行后续项目和产品功能规划。能够参考 ADR 可以减少开发、审查和架构决策所需的时间。ADR 还允许其他团队学习并深入了解其他项目和产品开发团队所做的考虑。
ADR流程
架构决策记录 (ADR) 是描述团队对他们计划构建的软件架构的一个重要方面做出的选择的文档。每个 ADR 都描述了架构决策、其上下文及其后果。ADR 具有状态，因此遵循生命周期。有关 ADR 的示例，请参阅附录。
ADR 流程输出架构决策记录的集合。此集合创建决策日志。决策日志提供项目背景以及详细的实施和设计信息。项目成员浏览每个 ADR 的标题以了解项目背景。他们阅读 ADR 以深入了解项目实施和设计选择。
当团队接受 ADR 时，它变得不可变。如果新的见解需要不同的决定，团队会提出新的 ADR。当团队接受新的 ADR 时，它将取代以前的 ADR。
项目成员应为影响软件项目或产品的每个具有重大架构意义的决策创建 ADR，包括以下内容（Richards 和 Ford 2020）：
- 结构（例如，微服务等模式）
- 非功能性需求（安全性、高可用性和容错性）
- 依赖关系（组件的耦合）
- 接口（API 和已发布的合约）
- 构建技术（库、框架、工具和流程）
详细点击标题