1. 课程导入
在软件研发的日常工作中，我们几乎每天都在做决策：数据库选 MySQL 还是 PostgreSQL？服务拆分按业务域还是按团队？缓存用 Redis 还是本地 Caffeine？接口用 REST 还是 gRPC？这些看似零散的选择，累积起来就构成了系统的骨架。问题在于，很多团队做了决策，却没有留下决策的"痕迹"——半年后新人问"为什么当初不用消息队列解耦"，没人答得上来；或者同一个技术选型在三个项目里出现三种做法，架构逐渐失控。架构决策与技术方案治理，正是为了解决"决策如何被做出、被记录、被复用、被约束"这一系列问题而存在的方法体系。
一、什么是架构决策
架构决策（Architecture Decision）指的是：对系统结构、关键质量属性或技术路线产生实质性影响，且变更成本较高的选择。它有三个判定特征：
- 影响面大：会约束多个模块、多个团队或后续多个迭代的设计空间。
- 变更成本高：一旦落地，回退需要付出显著的重构、迁移或数据改造代价。
- 存在真实取舍：至少有两个可行方案，各自在性能、成本、复杂度、可维护性上互有优劣。
反过来说，"变量命名用驼峰还是下划线""日志级别默认 INFO 还是 WARN"这类局部、低成本的约定，属于编码规范或团队约定，不必上升到架构决策层面。区分这一点很重要，否则决策记录会被大量琐碎条目淹没，治理也就失去了焦点。
二、什么是技术方案治理
如果说架构决策是"点"，技术方案治理就是"面"。它是一套持续运行的机制，用来保证技术选择在组织范围内保持一致性、可追溯性和可演进性。它通常包含四个动作：
- 决策产生：明确谁有权决策、依据什么信息决策、需要哪些人参与评审。
- 决策记录：把背景、选项、结论、理由和后果固化下来，形成可检索的资产。
- 决策执行：通过规范、脚手架、模板、门禁检查等方式，让决策真正落到代码和部署里。
- 决策复审：当业务或技术前提变化时，主动重新评估旧决策是否仍然成立。
治理不是审批，更不是"卡流程"。好的治理让正确的做法成为默认路径，让偏离需要理由，而不是让每个团队都从零开始摸索。
三、边界：治理管什么，不管什么
治理最容易失败的方式是"什么都管"。清晰的边界应当这样划定：
| 属于治理范围 | 不属于治理范围 |
|---|---|
| 跨系统的技术选型与集成方式 | 单个类的方法内部实现 |
| 关键质量属性的目标与验证方式 | 日常的代码风格与命名细节 |
| 服务边界、数据所有权、接口契约 | 某个页面的交互微调 |
| 技术栈的引入、升级与淘汰 | 临时性的排查脚本 |
| 安全、合规、成本等硬约束 | 团队内部的排班与分工 |
边界之外的事情交给团队自治，边界之内的事情必须有明确结论。这条线画得越清楚，治理越容易被接受。
四、核心价值
治理的价值可以归纳为四点：降低认知负荷（新人不必重新推导历史结论）、减少重复决策（相似场景直接复用）、控制架构漂移（偏离能被及时发现）、提升变更效率（知道约束在哪，改动就有边界）。它最终服务的是系统的长期可维护性和组织的交付速度，而不是文档本身。
五、本课程的学习路径
整个课程围绕"决策—记录—执行—复审"这条主线展开，从概念、方法、工具到案例逐步深入。下图展示了本课程的知识结构与实战目标之间的关系：
可以看到，课程不是停留在"讲道理"，而是要求你在学习过程中逐步产出四类可交付资产：一份完整的 ADR、一张技术选型评估表、一份治理检查清单，以及一套复审触发条件。这些资产可以直接带回团队使用。
六、一个贯穿课程的示例场景
为了让抽象概念有落点，课程会持续使用一个示例场景：某电商团队正在把单体订单系统拆分为微服务，面临"订单与库存是否共库""同步扣减还是异步最终一致""是否引入消息中间件"等决策。这些决策影响面大、变更成本高、存在真实取舍，正好符合架构决策的判定标准。后续章节会围绕它演示如何识别决策点、如何用质量属性场景做权衡、如何写出可追溯的 ADR，以及当业务量增长十倍时如何复审旧结论。
本章建立了三个基本认知：架构决策是有明确判定标准的、技术方案治理是一套持续机制而非一次性动作、治理必须有清晰边界。接下来的章节将沿着"决策—记录—执行—复审"这条主线，逐层展开具体方法与工具。