企业官网建设流程全解析

导读

本文围绕 architecture-decision-record 开源仓库中的核心方法论文档《Decision Sustainability Criteria》（决策可持续性标准）展开，系统讲解"决策可持续性"（decision sustainability）的五大判定标准：Strategic（战略性）、Measurable and Manageable（可度量且可管理）、Achievable and Realistic（可实现且务实）、Rooted in Requirements（扎根于需求）、Timeless（经久不衰）。读完本文，你将获得一套可直接用于撰写与评审 Architecture Decision Record（ADR）的评估框架，并了解如何结合仓库中的模板、示例与配套指南，让架构决策在数月甚至数年后依然可追溯、可度量、可维护。

什么是"决策可持续性"？

在软件架构领域，架构决策记录（ADR）用于记录"重要的架构决策及其背景与后果"——这是仓库中 什么是 ADR 一文的定义。但"写下了"并不等于"可持续"：一条决策记录可能语义模糊、粒度失当、理由缺失，也可能在技术栈更迭后迅速过时。

"决策可持续性"正是针对这一问题提出的概念。它源自对可持续架构设计决策的研究，其核心主张是：架构决策不仅要当下正确，还要在未来长期可理解、可维护、可追溯。为了把这一抽象概念落到可操作的层面，仓库文档从实践推导出五个关键标准，用于回答一个根本问题："这条决策能否在未来持续成立？"

标准一：Strategic（战略性）

核心含义：在做决策时，决策者必须审视决策的战略性后果，尤其是长期影响——例如未来的运维与维护成本。

原文要点：During decision making, someone looking at strategic consequences should consider things such as the decisions' long-term impact—for example, future operations and maintenance effort.

深入解读：这一标准要求把决策放到时间轴上考量。许多架构决策在当下看起来成本很低，却会在未来数年持续消耗团队精力。举例来说：

• 选择一个运维工具链时，不仅要看今天的接入成本，还要评估未来升级、排障、招聘相关技能人才的长期成本；
• 选择一个数据存储方案时，要考虑长期的数据迁移成本与锁定风险。

仓库佐证：仓库中的 选择数据库技术示例 正是"战略性"思维的产物——该 ADR 在 Consequence 部分明确写道："选择文档数据库后，我们需要投入学习并理解所选具体技术，同时确保应用的数据模型与文档数据库的数据模型良好匹配，以最大化性能与可扩展性。"这就是把"未来的运维与维护成本"显式写进决策后果的范例。

自查问题：

• 这条决策一年后、三年后的运维与维护成本是多少？
• 它是否会限制未来的演进方向？
• 决策的 Consequences 是否覆盖了长期影响，而不只是当下收益？

标准二：Measurable and Manageable（可度量且可管理）

核心含义：决策的结果应能依据客观标准（理想情况下是数值化的）随时间度量与评估；同时，决策的粒度必须被有意识地控制，决策之间的依赖数量也应受到限制。

原文要点：You can measure and evaluate a decision's outcome over time according to objective criteria, ideally numeric ones (as, for instance, propagated by quality attribute scenarios and workshops). Capturing all fine-grained decisions isn't possible, so architects must limit the decisions' granularity to a certain level of detail (such as creating a design class). This will lead to a more sustainable set of decisions and fewer traceability links. Moreover, limiting the number of dependencies between decisions reduces changes' ripple effect.

深入解读：这一标准包含两个层面：

1. 可度量（Measurable）：决策不能只有定性描述，而应尽可能关联可验证的客观指标。质量属性场景（quality attribute scenarios）与研讨会（workshops）是经典做法——例如把"性能"决策锚定到具体的响应时间阈值、把"可用性"决策锚定到具体的可用性百分比。有了数值化指标，决策是否被执行、执行效果如何，都能被客观检验。

2. 可管理（Manageable）：架构师不可能也不应该为每一个细小的设计选择（例如"创建一个设计类"级别的细节）写 ADR。必须：

• 控制决策粒度：只记录"架构级重要"的决策，避免把 ADR 日志变成琐碎变更流水账；
• 控制决策间的依赖数量：决策 A 依赖决策 B 越少，未来修改 A 时引发的"涟漪效应"（ripple effect）就越小；
• 减少可追溯性链接数量：粒度适当的决策集天然拥有更少的 traceability links，更易维护。

仓库佐证：仓库在维护层面的实践与"可管理"标准高度一致。根 README.md 与 AGENTS.md 明确规定了内容治理规则：每个内容目录中README.md必须是index.md的符号链接，只允许编辑index.md；英文源内容统一放在locales/en-001/，其余 30 个语言环境各保持 205 个文件的固定结构。这种"统一粒度 + 严格结构"的做法，正是把决策知识库本身变成"可管理"对象的工程实践。

自查问题：

• 这条决策关联的指标是数值化的吗？能否客观判定它是否被遵守？
• 决策粒度是否合适？是否细到"设计类"级别以下、本不该进 ADR？
• 它与其它决策的依赖关系是否最少化？

标准三：Achievable and Realistic（可实现且务实）

核心含义：解决方案与问题之间的适配理由应务实选择并明确写出；架构师应明确表明自己避免了过度设计（over-engineering）或欠设计（under-engineering），即遵循"足够好"（good enough）原则。

原文要点：The rationale for fitting the solution to the problem should be chosen pragmatically and made explicit. For example, architects can indicate that they have taken care to avoid over- or underengineering (that is, they should apply the "good enough" approach).

深入解读："可实现且务实"强调的是理由的显式化。现实中许多 ADR 只写"我们选择了 X"，却不写"为什么 X 对当前问题足够好"。可持续的决策应当把适配逻辑讲清楚：

• 为什么这个方案与问题规模匹配？
• 为什么没有选择更复杂/更简单的方案？
• 当前约束（时间、成本、团队规模）如何影响了取舍？

"good enough"并不是降低标准，而是有意识地在资源约束下做出适配，并把这种适配意图记录下来，防止后人误读为疏忽。

仓库佐证：这一标准在仓库的 Michael Nygard 决策记录模板 中得到了结构性支撑：模板要求 ADR 必须包含 Context（当前看到的问题是什么）、Decision（提议/正在做的变更是什么）、Consequences（变更后什么变得更容易或更困难）。其中 Context 与 Consequences 正是把"为什么适配"显式化的位置。仓库 如何写好 ADR 进一步要求 Rationale 部分应包含各种备选方案的利弊、功能对比与成本/收益讨论——这正是务实理由的完整形态。

自查问题：

• 决策理由是否写明了"为什么这个方案与问题匹配"？
• 是否显式说明避免了过度设计或欠设计？
• 备选方案的利弊是否被记录并权衡过？

标准四：Rooted in Requirements（扎根于需求）

核心含义：决策应扎根于领域特定的架构经验与上下文，充分考虑公司环境、项目需求与约束，以及开发团队当前的技能、培训预算与流程。

原文要点：Decision making should be grounded in domain-specific architecting experience and context. It should take into account the company environment as well as project requirements and constraints, including the development team's current skills, training budget, and process.

深入解读：这一标准反对"从教科书直接套答案"。同样一个技术选型，在初创公司与金融合规企业、在 Go 团队与 Java 团队中的正确决策可能截然不同。可持续的决策必须回答：

• 这个决策是否符合本项目所在领域的最佳架构经验？
• 是否考虑了公司环境（组织流程、合规要求、业务优先级）？
• 团队现有技能能否支撑落地？是否需要培训预算？培训成本是否计入决策权衡？

仓库 如何写好 ADR 对 Context 部分给出了精确要求，可视为本标准的落地清单："解释组织的处境与业务优先级；纳入基于团队社交结构与技能构成的理由与考量；包含相关的利弊，并用与你的需求与目标一致的语言描述。"这正是把决策"扎根于需求"的具体写法。

仓库佐证：仓库中的 时间戳格式示例 是"扎根于需求"的教科书案例。该 ADR 的 Context 明确列出了真实约束：JSON 消息没有原生时间戳格式需要选择序列化方式、部分应用使用本地时间而非 UTC、不同系统的时间精度需求不同（Linuxdate命令默认秒级精度，而纳斯达克交易所需要纳秒级精度）。决策（ISO 8601 纳秒精度格式）完全由这些具体需求推导而来，而非凭空选择。

自查问题：

• 决策是否结合了领域经验与项目具体上下文？
• 是否考虑了团队技能、培训预算与组织流程？
• Context 是否写清了组织处境与业务优先级？

标准五：Timeless（经久不衰）

核心含义：决策应建立在不太可能很快过时的经验与知识之上；例如选择平台中立（platform-neutral）的架构模式或策略。

原文要点：Decisions should be based on experience and knowledge that won't likely be soon outdated. For example, architects can choose platform-neutral architectural patterns or tactics.

深入解读："经久不衰"并非要求决策永不改变，而是要求决策所依赖的知识基础具有较长的半衰期：

• 优先选择平台中立的架构模式/策略（如分层架构、端口与适配器、事件驱动等抽象层次的决策），它们不绑定特定厂商或框架版本；
• 尽量避免把决策建立在具体产品的短期特性上（如某个 SaaS 的临时促销性功能）；
• 对可能随时间变化的信息（成本、排期、规模数据）要标注时间戳——这正是仓库 如何写好 ADR 中 "Timestamps: Identify when each item in the ADR is written" 的要求，因为"成本、排期、扩展性等要素会随时间变化"。

仓库佐证：仓库自身的内容治理也体现了"经久不衰"思维——产品名（如 amazon-web-services、google-cloud-platform 等）在多语言翻译中保持原文不译（见 scripts/audit-locales.py 中的PRODUCT_OK集合），以避免专有名词在翻译中失真；而知识性内容则持续沉淀为模板与示例，不绑定任何单一技术版本的存续期。

自查问题：

• 这条决策依赖的知识基础在 5 年后仍成立吗？
• 它是否绑定于特定平台、厂商或版本？
• 易变信息（成本、排期、规模）是否标注了记录时间？

五标准的协同使用：评估一条 ADR 的完整检查清单

五个标准并非孤立条款，而是一条决策从"当下成立"走向"未来可持续"的完整链条。将它们组合成评审清单，可用于新 ADR 撰写后的自检或团队评审：

仓库的示例集合（如 时间戳格式示例、选择数据库技术示例）以及 11 套模板（见 locales/en-001/templates/）为这五标准提供了大量可对照的实践范本。

配套实践一：八条实现可持续决策的指南

仓库的姊妹文档 实现可持续决策的指南 总结了八条实践经验，与五标准互为表里，可作为落地的操作路径：

1. 初始文档采用精简/极简方式（呼应 Measurable and Manageable 的粒度控制）；
2. 优先记录所有足以影响目标架构理解的重要决策（呼应 Strategic）；
3. 仅在初步工作完成后、决策者确信决策短期内无需修订时，才用完整模板详化特别重要的决策（呼应 Timeless）；
4. 用第 1 步的精简版作为详化决策的概览，也用于平凡或显而易见的决策；
5. 尽可能复用既有架构知识（来自指导模型或其他来源），审阅、扩展并适配到具体决策上下文（呼应 Rooted in Requirements）；
6. 确保在决策与需求、架构设计/代码之间建立可追溯性链接（呼应 Measurable）；
7. 提供自动化一致性检查，确保变更后追溯链接保持同步，并限制决策与其他软件制品之间的依赖数量（呼应 Manageable）；
8. 持续、有力地应用理由撰写指南——理由是决策文档中最重要的部分，因为它给出了 rationale（呼应 Achievable and Realistic 的显式化）。

第 6、7 条尤其值得注意：可追溯性（traceability）与自动化检查正是"Measurable and Manageable"标准的工程化实现。

配套实践二：把可持续性变成可执行的检查——fitness functions

五标准中的"可度量"在工程上最直接的落地方式，是仓库文档 把决策写成代码的适应度函数 所介绍的 fitness functions（适应度函数）：用编程代码编写的客观自动化检查，用于验证决策是否被持续遵守。

• "决策记录（decision record）记录决策，而适应度函数保证决策"——例如决策是"我们为审计需求使用事件溯源"，对应适应度函数是"在持续集成服务器上测试所有状态变更必须产生事件"；
• 适应度函数通过/失败二元判定，让工作可见清晰（Measurable）；
• 在每次提交与构建上运行，成为"活规则"（可持续性的持续保障）；
• 自动捕获决策规则错误，为重构提供信心；
• 在不制造瓶颈的前提下保证标准执行，支持可扩展治理。

将适应度函数与五标准结合：每条 ADR 的 Consequences 若能提炼出一条可自动执行的检查，该决策就从"文档承诺"升级为"可验证的工程约束"。

配套实践三：让可持续性进入团队工作流

可持续性不仅是文档属性，更是团队实践。仓库 团队协作建议 给出了关键提醒：决策记录的价值在于让团队"想得更聪明、沟通得更好"，而不是事后的强制文书工作。实践中，许多团队更偏好用 "decisions" 目录名而非缩写 "ADRs"；对于文档的可变性，理论上不可变（immutable）最理想，但实践中"在既有 ADR 中追加新信息并标注日期与来源"的活文档（living document）方式对团队更有效——这与五标准中"易变信息带时间戳"（Timeless）的要求完全吻合。

此外，仓库的 文件命名规范（使用现在时祈使动词短语、小写加连字符、Markdown 扩展名，如choose-database.md、format-timestamps.md）保证了 ADR 日志本身的可读性与可管理性——命名即粒度控制的一部分。

结语：用五标准为架构决策"做体检"

决策可持续性五标准为 ADR 实践提供了一套可操作的评估维度：Strategic审视长期代价，Measurable and Manageable要求可度量、粒度与依赖可控，Achievable and Realistic强调理由显式化与"足够好"原则，Rooted in Requirements主张扎根于真实上下文，Timeless追求知识基础的持久性。将它们与仓库的八条指南、fitness functions 工程实践以及丰富的模板示例（全部位于 locales/en-001/）结合使用，你的每一次架构决策都将更有把握经得起时间检验。