架构决策的框架 | @Sting (atSting.com)

关键要点

用于制定架构决策的框架可以清晰地说明决策制定过程以及谁应该参与。
内部技术雷达可以帮助团队了解技术前景，并就使用哪些技术做出明智的决定。
技术标准可以确保横切关注点的更广泛一致性，并降低采用次优新技术的风险。
最后，架构决策记录 (ADR) 可以捕获遵循标准和雷达的特定决策，并提供其推理的历史记录
这些方法组合在一起满足了架构决策治理的所有需求，并提供了一个简单的使用框架

架构决策的简单框架

软件工程师必须做出架构决策才能继续开发。我们可以为我们的新微服务使用 Python 而不是 Java 吗？我们可以在开发新的前端库时使用另一个打包器吗？我应该与我的经理或其他团队就存储库结构达成一致吗？

设计 REST API 时应该使用 snake_case 还是 camelCase? 公司需要建立一个清晰的框架来做出这些决策，谁需要参与，以及在哪里可以找到有关已完成决策的信息。

使这样的框架正确至关重要，因为它将定义不同团队拥有多少自由和自主权。这应该符合业务需求和您在特定阶段试图建立的公司文化。

这会影响人们对不同领导角色的看法、经理和个人贡献者在技术决策中的角色，以及不同职业级别的授权水平。虽然每家公司都会根据其组织边界、成熟度和需求选择不同的负责人和不同程度的团队自治，但该框架可能需要非常相似的构建块。

在这篇文章中，我想根据我最近在不同规模的组织中的工作经验，分享这种用于制定架构决策的框架可能具有的关键构建块。这些构建块包括您自己的技术雷达、技术标准和架构决策记录 (ADR)。

一、建立自己的技术雷达

有些人可能知道 Thoughtworks，他们最初建立了他们的技术雷达。Thoughtworks 捕捉并发布他们与整个行业的客户在现场看到的东西。

同样，您可以构建自己的雷达，显示您公司使用或计划使用的不同技术、工具和方法的成熟度。技术雷达是贵公司当前和所需技术堆栈的可视化表示。

你应该定义不同的阶段——评估、试用、采用和持有，以及给定技术应该如何通过这些阶段的过程。

技术雷达示例

首先，新技术在评估中，这意味着它正在积极研究和评估。评估状态通常以概念证明和我们环境中技术使用的优缺点的广泛列表结束。然后，我们与各自的内部实践社区或可能与之互动的团队讨论结果。如果论点列表和概念实施证明令人信服，下一步就是受控试用期。在试用期间，该技术仅在单个用例的生产中处于领先地位。如果该步骤成功，我们将宣布采用该技术，并为任何团队进一步使用开绿灯。如果新技术正在取代以前使用的技术，则可能需要发出信号。

Radar 帮助团队了解技术前景，并就使用哪些技术做出明智的决定。如果你保持 Radar 更新，公司中的每个人都知道正在使用的技术的最新状态及其对业务的影响。

二、引入内部技术标准

第二个组成部分是引入技术标准。技术雷达捕获技术、平台、工具、语言和框架，以及它们在整个组织中的采用程度。但是，这可能无法满足所有需求。为适用于系统不同部分的事物建立一致的做法可能会有所帮助。例如，您可能希望确保所有日志记录都以相同的格式完成并包含相同的信息。或者，如果您使用的是 REST API，您可能希望围绕它的设计和使用方式建立一些约定，例如使用什么标头或如何命名。此外，如果您使用多种类似技术，指导何时使用每一种技术会很有用。技术标准定义了在公司内选择和使用技术的规则。

谁应该负责标准？技术标准应由相关领域的跨职能专家团队创建和维护。它们应该定期审查并根据需要进行更新，以跟上技术领域的变化。应鼓励团队遵循标准并就其有效性提供反馈。格式可能不同，但可能会有详细的解释和代码示例。它可以更正式并遵循例如RFC 格式框架，也可以更随意，具体取决于您的偏好和工程文化。Zalando 的 RESTful API 和事件指南是公开共享的内部技术标准的一个很好的例子。除了 API 标准之外，您可能还想引入日志记录和监控、部署以及 QA 标准。

基于内部标准，您可以创建质量门，例如检查测试覆盖率、集成代码 linter 检查命名约定或格式，或验证您的架构或存储库结构的适应度函数。结合自动检查、在新入职人员入职期间使用标准、代码审查或结对编程，将有助于确保标准得到使用并带来价值。除了检查是否遵守标准的大门外，这也是讨论平台工程在铺设道路方面的价值的机会。不要简单地告诉人们做错了什么——让默认情况下做正确的事情变得容易。

三、采用架构决策记录 (ADR) 实践

调整架构决策的第三个构建块是创建 ADR 或轻量级 RFC。ADR 是一种记录架构决策及其推理的方法。它们提供重要决策的历史记录，并帮助团队理解为什么选择特定方法。ADR 应该由负责做出架构决策的团队创建。它们应该包括诸如正在解决的问题、考虑的备选方案、做出的决定及其背后的原因等信息。它们是不可变的文件。当重新审视给定的决策时，通常会创建一个新文档。ADR 实践越来越受欢迎，因此AWS和GCP等主要云提供商将其添加到各自的文档中。

虽然技术雷达和标准应该为技术决策提供指导和预期边界，但 ADR 捕获推理并记录特定的一次性决策——创建新服务或包、引入新技术或任何其他主要架构变更的原因. ADR 通常存储在中央存储库或文档工具中，所有相关团队都可以访问。他们还帮助新团队成员快速了解整体架构和重大决策背后的原因。

ADR 审查流程可用于多种目的——审查和批准决策以及共享知识。虽然让每个受影响的人都参与 ADR 审查是很常见的，但与更多人分享它可以提高整个组织的整体架构意识。此外，在内部技术圈中展示 ADR 以收集更多反馈也很有用。有时，您可能有一位工程师在过去解决了类似的挑战，但现在并没有直接处理这些挑战。

与前两个支柱一样，涵盖最终确定 ADR 的最终决定权以及哪些决策被认为重要到需要 ADR 的过程对于每个组织都是不同的。为避免重复，您可以使用 ADR 就构建新的主要系统变更的特定设计选择达成一致，同时就使用 Radar 和标准的语言、工具和实践的更广泛使用达成一致。有了内部技术雷达和标准，就 ADR 达成一致应该是一项精简和直接的工作，因为最重要的技术选择和原则已经一致。

架构决策需要正式的文档和确定的形式。通常，架构决策必须需要包含以下几个元素：

架构决策的概述：描述了本次架构决策做了什么决定。
唯一编号：在项目中唯一的编号，避免混淆。
架构问题：所要解决的架构问题是什么。
假设：在上下文中的一些确定性的假设。这也是架构决策依赖的重要组成部分。如果假设变了，那架构决策就不再成立。
备选：该架构问题存在的备选方案。
架构决策：选择了备选方案中的哪一个方案。
决策理由：为什么选择该备选方案。
架构含义：所采取的觉得对方案的其他元素的影响，或对后面的结果的影响。

之所以架构设计是一个确定性的设计，就是因为所有的架构设计图上的元素，大多都需要经过架构决策的推敲和洗礼。其实大家可以想象到。架构决策通常都不是一个单一个的决策。而是一生二、二生三、三生万物的过程。一个架构决策套一个架构决策，形成一整套决策树，来构成了整个架构设计。这个架构决策树的根节点，就是架构原则，基于架构原则，开枝散叶，形成了整个架构设计。

结论

技术雷达、技术标准和 ADR 共同构成了一个框架，该框架提供了一种清晰一致的方法来制定架构决策、降低采用新技术的风险并提供重要决策的历史记录。通过建立架构决策框架，团队可以确保他们的技术堆栈与他们的业务目标保持一致，并且他们的团队拥有做出明智决策所需的信息和指导。

您的团队拥有的自由度，以及更改雷达、标准或 ADR 的过程，将塑造您的工程文化。一些组织的目标是彻底的团队自治，而一些组织的目标是高度的一致性和一致性，这些限制性更强。例如，一种可能的方法是让您的高级技术领导参与雷达和标准的变更，这将指导进一步的技术决策，并将 ADR 留给负责各自软件功能的团队。您可以选择框架并根据您公司的需要进行调整。