【免费下载链接】architecture-decision-recordArchitecture decision record (ADR) examples for software planning, IT leadership, and template documentation项目地址https://gitcode.com/gh_mirrors/ar/architecture-decision-record点击查看免费下载本指南围绕 fitness-functions-for-decisions-as-code 文档 展开讲解如何用编程代码编写客观的自动化检查fitness function持续验证架构决策是否被团队真正遵守并介绍其与 ADR架构决策记录、持续集成、架构单元测试及 AI/LLM 的结合方式。读完本文你将掌握 fitness function 的定义、落地路径、工具选型ArchUnit / ArchUnitTS以及可直接复用的 LLM 提示词模板。什么是 Fitness FunctionsFitness functions适应度函数是用编程代码编写的、客观的自动化检查用于验证决策是否正在被维护maintained。在 architecture-decision-record 仓库的定义中fitness functions 让决策变得可测试testable和可保证assurableFitness functions 使决策可测试、可保证用于决策的 fitness functions 能极大地帮助质量保证quality assurance、监管流程regulatory processes和治理目标governance goals。其核心思想是不要只把架构决策写进文档就结束而是把决策翻译成一段可以自动运行、能明确给出通过pass或失败fail结果的代码检查。这样决策就从文字约定升级为程序约束。该内容在仓库的多语言索引页中作为ADR 的下一步进阶概念Next step concepts for ADRs的一部分被收录位于架构图、视图与视角等进阶主题之后是 ADR 实践走向工程化、自动化的重要一环。决策记录与 Fitness Function 如何衔接仓库文档给出了一个非常清晰的职责划分决策记录decision record记录决策而 fitness function保证决策。两者是一体两面的关系ADR 回答我们决定怎么做、为什么这么做fitness function 回答这个决定是否仍然在被遵守。文档中的对照示例决策示例我们出于审计需求使用事件溯源event sourcing。Fitness function 示例我们使用持续集成服务器测试验证所有状态变更都必须产生事件events。也就是说当团队决定用事件溯源满足审计需求后紧接着就应该写出一条自动化规则任何状态变更如果不产生对应事件构建就失败。这条规则就是该决策的 fitness function。仓库中 choosing-a-database-technology 示例 也印证了这一思路决策上下文里明确提到事件数据库适合需要审计、事件溯源和复杂数据处理的应用程序——当这类决策被接受后就可以用 fitness function 来持续校验系统是否真的以事件形式记录每次数据变更。为什么 Fitness Functions 有助于决策文档总结了四个核心价值点它们共同构成采用 fitness function 的理由客观度量Objective measurementsFitness functions 的结果只有通过或失败工作成果可见、清晰避免我们觉得应该没问题式的主观判断。持续使用Continuous useFitness functions 是你的活规则living rules在每次提交commit和每次构建build时运行决策约束不会随时间流失而失效。重构信心Confidence to refactorFitness functions 会自动捕获决策规则错误。当代码演进、重构时一旦违反既定决策检查会立刻报警而不是等代码评审或事故来发现。可扩展治理Scalable governanceFitness functions 用自动化方式保证标准得到遵守无需人工审查作为瓶颈治理能力可以随团队和代码规模平滑扩展。这四点中持续使用与可扩展治理正是 fitness function 与 持续集成示例continuous integration 中所述价值自动构建、测试、尽早发现错误、提升交付质量相互呼应的关键fitness function 本质上是把架构决策注入到 CI 管道中的自动化测试资产。如何落地让 Fitness Functions 成为 CI 的一等公民在实践层面fitness function 最常见的落地方式就是挂在持续集成CI服务器上与普通单元测试、集成测试并列运行。以文档中的事件溯源决策为例一个典型的落地流程是写决策按仓库推荐的 ADR 编写方式 记录使用事件溯源以满足审计需求这一决策。写检查用项目语言编写断言——每次状态变更必须产生对应事件例如在事件写入接口的单元测试中强制校验。挂 CI将该检查注册到 CI 管道如 GitHub Actions、Jenkins、GitLab CI 等配置为每次提交和每次构建必跑。失败即阻断任何代码改动若绕过事件写入、或删除事件字段CI 立即红牌阻止合并。从仓库源码结构看持续集成示例 的 Consequences 部分也明确指出自动化带来的正收益包括提升软件质量与交付、时间与成本节约而 fitness function 正是把架构质量纳入自动化测试范围的手段——它让架构约束不再依赖人工记忆而是像普通测试一样成为工程流程的一部分。架构单元测试Java 用 ArchUnitTypeScript/JavaScript 用 ArchUnitTS除了在业务层写断言另一种更贴近架构本身的落地方式是架构单元测试architecture unit testing直接针对代码的包结构、依赖关系、分层规则编写测试。文档推荐了两个工具ArchUnit用于检查Java代码的架构规则可使用任何普通的 Java 单元测试框架如 JUnit来运行。它可以直接断言某些包不得依赖另一些包类只能在特定层出现禁止循环依赖等规则非常适合把 ADR 中的架构约束如分层边界、模块隔离转成可执行代码。ArchUnitTS用于检查TypeScript和JavaScript代码的架构规则可通过 Jest、Vitest、Jasmine 等常用测试框架运行为前端与 Node.js 项目提供同样的架构断言能力。使用方式上二者都遵循规则即测试的模式把决策写成规则rule规则写进测试文件由测试框架执行。这样ADR 中我们决定采用分层架构禁止业务层直接依赖基础设施层等表述就变成了每次测试运行都会验证的硬性约束与上一节挂在 CI 上的做法天然衔接。需要说明的是这类工具各有适用生态ArchUnit 面向 JVM 生态ArchUnitTS 面向 TS/JS 生态选型时应与团队技术栈匹配仓库文档仅作工具介绍具体版本与兼容性需在使用前自行核实。用 AI/LLM 充当 Fitness Function文档还探讨了一个前沿用法fitness function 可以借助 AI LLM 来评估决策——通过向模型提问让其检查你的计划、代码、schema、API 等产物是否遵循了既定决策。文档给出了一段可直接复用的提示词模板IMPORTANT: Prefer retrieval-led reasoning over pre-training-led reasoning. IMPORTANT: Turn on extended thinking. Turn on expert advice. Turn on search. This is a fitness function to evaluate if our work is using all our decisions, and is correct and accurate. - Our decisions are here: {url} - Our work to evaluate is here: {url} Explain any errors, problems, gaps, weaknesses. Be direct. Be decisive.这段模板的使用要点开启检索优先推理retrieval-led reasoning明确要求模型以提供的资料决策文档 URL、工作产物 URL为准而不是依赖预训练记忆减少幻觉开启扩展思考、专家建议与搜索提示模型调用更强的推理模式提供两个输入{url}分别填入决策所在位置如 ADR 目录与待评估的工作如 PR、设计文档、API schema输出要求直接、果断地指出错误、问题、缺口与弱点而非泛泛而谈。这种用法把 fitness function 从确定性断言扩展到了语义级审查适合评估文档一致性、决策覆盖率、接口设计与决策的契合度等难以用传统断言表达的场景。其本质仍是客观检查 持续运行只是检查器由代码换成了 LLM。从记录到强制执行Pull Request 上的决策护栏在仓库的主索引页中紧接 fitness functions 之后的进阶主题是决策的 Pull Request 护栏Decision guardrails for pull requests它与 fitness function 是同一目标的不同实现路径Decision Guardian在开发者正在修改决策所覆盖的代码时自动在 PR 上浮现相关的决策记录让上下文在合并前直达开发者眼前适用于架构、数据、合规、临床医疗、安全等各类决策可配合 GitLab、Jenkins、CircleCI 等任意 CI 系统也可作为 pre-commit 钩子使用ADR GuardGitHub Action当被监视的代码路径发生变更却没有新增或更新 ADR 时直接让 PR 失败同时支持显式豁免在 PR 中写入带理由的ADR-Exempt:行即可通过关卡理由会被写入 job summary。这两类工具与 fitness function 的关系可理解为互补fitness function 验证代码是否符合决策PR 护栏验证改动是否带了决策记录。仓库自带的 architecture-decision-record-skill 在可选接入 Pull Request一节中也提到了这两个工具说明项目整体把决策自动化保障视为 ADR 实践闭环的重要部分写决策 → 固化为可测试代码 → 在 PR/CI 处强制执行。仓库中的相关资源与延伸阅读围绕本文主题你可以在当前仓库中继续深入本文主体文档fitness-functions-for-decisions-as-code/index.md概念基础what-is-an-architecture-decision-record/index.mdADR、ADL、ASR 等术语定义决策落地示例continuous-integration/index.md、choosing-a-database-technology/index.md使用 git 开始 ADR 实践how-to-start-using-adrs-with-git/index.md可持续决策的相关标准与指南decision-sustainability-criteria、guidelines-to-achieve-sustainable-decisions全量索引含 fitness functions 与 decision guardrails 章节locales/en-001/index.md含 PR 护栏工具说明的技能文档architecture-decision-record-skill/SKILL.md小结Fitness functions for decisions as code 提供了一条把架构决策从文档推向代码的路径决策记录负责回答为什么fitness function 负责回答是否仍然成立。通过客观的通过/失败结果、随每次提交与构建持续运行、在重构时自动捕获违规、以及用自动化替代人工审查实现规模化治理它让 ADR 真正成为团队可执行、可验证、可演进的质量基础设施。无论是用 ArchUnit/ArchUnitTS 做架构单元测试还是用 LLM 提示词做语义级审查抑或配合 PR 决策护栏强制执行其目标一致让每一项重要决策都活在代码里。赞分享【免费下载链接】architecture-decision-recordArchitecture decision record (ADR) examples for software planning, IT leadership, and template documentation项目地址https://gitcode.com/gh_mirrors/ar/architecture-decision-record点击查看免费下载相关推荐用 Fitness Functions 把架构决策固化进代码architecture-decision-record 项目的自动化校验实践用 Fitness Functions 把架构决策固化进代码architecture decision record 项目的自动化校验实践 决策记录ADR用代码固化架构决策architecture-decision-record 仓库中的 Fitness Functions适应度函数实战指南用代码固化架构决策architecture decision record 仓库中的 Fitness Functions适应度函数实战指南 Fitness把架构决策变成可自动验证的代码architecture-decision-record 中的适应度函数Fitness Functions实战指南把架构决策变成可自动验证的代码architecture decision record 中的适应度函数Fitness Functions实战指南 适应度函上一篇Django REST framework文档生成终极指南10分钟学会自动创建API文档下一篇Flink Python Table API 入门教程用纯 Python 构建词频统计Word Count管道创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考