治理与方法论

这一课你将能做到

1. 说清楚 TOGAF 的 ADM 循环在中小团队如何裁剪落地
2. 为本站设计一套轻量架构治理机制：评审清单 + ADR 流程 + 技术债台账
3. 解释 Scrum、Kanban、SAFe 各自的适用团队规模，并为本站 15 人团队做选择

为什么要学

架构不是设计出来就完事的——代码会腐化、团队会扩张、边界会模糊。没有治理机制，再漂亮的架构图一年后都会变成「文档里的架构」和「实际跑的架构」两张皮。

人话：治理就是给架构装「物业」。房子是设计建出来的，但没有物业管：乱搭乱建（随意加依赖）、管道老化（技术债）、违章改造（绕过架构规范），三年后小区没法住人。

先建立图像

架构治理的三层体系：

┌─────────────────────────────────────────┐
│ 战略层：技术雷达 / 架构原则                 │
│ 「我们不用闭源中间件」「数据不出私有云」      │
├─────────────────────────────────────────┤
│ 机制层：评审 + ADR + 技术债台账            │
│ 新服务准入 checklist / 重大决策留痕        │
├─────────────────────────────────────────┤
│ 工具层：架构适应度函数（Fitness Function）  │
│ ArchUnit 校验分层 / 依赖扫描 / 契约测试     │
└─────────────────────────────────────────┘

跟着做

步骤 1：TOGAF ADM 的中小团队裁剪

完整 ADM 有 8 个阶段，本站裁剪为四步循环：

原版 ADM: A架构愿景→B业务架构→C信息系统架构→D技术架构
         →E机会方案→F迁移规划→G实施治理→H变更管理

本站裁剪版（每季度一轮）:
1. 愿景对齐（半天）：本季度业务目标 → 架构要支撑什么
2. 现状盘点（1 天）：架构图更新 + 技术债台账复审
3. 差距与方案（2 天）：列出差距 → 排序 → 排进迭代
4. 实施守护（持续）：PR 里 ArchUnit 自动校验 + 月度评审

步骤 2：用 ArchUnit 把架构规范变成代码

治理不能只靠自觉，要让规范在 CI 里自动执行：

@AnalyzeClasses(packages = "com.coderoadmap")
class ArchitectureTest {

    // 分层规则：Controller 不许直接访问 DAO
    @ArchTest
    static final ArchRule layered = layeredArchitecture()
        .consideringAllDependencies()
        .layer("Controller").definedBy("..controller..")
        .layer("Service").definedBy("..service..")
        .layer("Dao").definedBy("..dao..")
        .whereLayer("Controller").mayNotBeAccessedByAnyLayer()
        .whereLayer("Service").mayOnlyBeAccessedByLayers("Controller")
        .whereLayer("Dao").mayOnlyBeAccessedByLayers("Service");

    // 领域规则：领域层不许依赖 Spring（保持纯净）
    @ArchTest
    static final ArchRule domainPure = noClasses()
        .that().resideInAPackage("..domain..")
        .should().dependOnClassesThat()
        .resideInAPackage("org.springframework..");
}

PR 违反规则 → CI 直接失败。规范从「文档里的建议」变成「过不去的门禁」。

步骤 3：技术债台账管理

| 编号 | 债务 | 引入原因 | 利息（不还的代价） | 本金（偿还成本） | 优先级 |
|------|------|---------|------------------|----------------|--------|
| TD-01 | 订单模块未拆服务 | 当初赶上线 | 每次发布全量回归，30min→2h | 3 人周 | 高 |
| TD-02 | 课程表缺索引 | 早期数据少无感 | 慢查询已出现 3 次 | 0.5 人天 | 高 |
| TD-03 | 前端还在用旧组件库 | 历史遗留 | 新需求开发慢 20% | 5 人周 | 中 |
| TD-04 | 单点 Redis 无哨兵 | 省钱 | 挂了就全站缓存失效 | 1 人周 | 高 |

规则：每个迭代固定 20% 容量还债，优先还「利息高、本金低」的。

讲清楚要点

1. 治理的目标是一致性，不是完美：十个服务用同一种「够用」的模式，胜过十个服务各自「最优」。认知一致性让小团队维护大系统成为可能。
2. ADR + 自动化校验是治理的最小可行组合：ADR 管「为什么这么决策」，ArchUnit/契约测试管「规则是否被遵守」。两者成本极低，收益极大。
3. 敏捷方法论按团队规模选：5 人以下 Kanban（流程最轻）；5-30 人 Scrum（节奏感强）；跨多团队大型组织才考虑 SAFe。框架是工具，站会开了三周没价值就砍掉。
4. 技术债是金融工具不是耻辱：为了赶上线窗口主动借债是合理商业决策，关键是有台账、有计划还。失控的不是借债，是不知道自己欠了多少。
5. 企业框架（TOGAF/ITIL/PRINCE2）学思想不学形式：小团队不需要 TOGAF 全套文档，但「愿景→现状→差距→迁移」的思考闭环值得每个架构师内化。

你可能会懵的地方

• 治理会不会降低团队效率？ 好的治理减少的是「不一致带来的隐性沟通成本」。新服务准入 checklist 看似多一道手续，实际上避免了「又有人引入一个新 MQ 中间件」的运维灾难。判断标准：治理项是否自动化（自动化的没负担），是否解决过真实事故。

• Scrum 和 Kanban 核心区别？ Scrum 有固定迭代（Sprint）和角色（PO/SM），强调承诺和节奏；Kanban 没有迭代，强调流动和限制在制品（WIP）。需求变化剧烈的团队（本站早期）适合 Kanban；需要可预测交付节奏的适合 Scrum。

• SAFe 为什么争议大？ SAFe 试图把敏捷扩展到几百人组织，但引入了繁重的角色和流程，常被批评为「披着敏捷外衣的瀑布」。只有真正多团队依赖复杂的大组织（车企、银行）才值得评估，而且落地需要专业顾问。

• 架构评审委员会（ARB）怎么不变成官僚机构？ 三条原则：评审基于公开的清单（不是评委个人好恶）、提供自助通道（清单内绿灯事项不用上会）、例会制而非随叫随审。评审输出必须是「通过/有条件通过/拒绝+理由」，而不是漫谈。

• SAP/Salesforce 这类企业平台和架构师什么关系？ 大中企业里 ERP/CRM 平台是架构的重要约束：定制开发的边界、数据集成模式（IDoc/API/CDC）、升级策略都需要架构师参与。原则：平台能力优先配置而非定制，定制代码隔离在防腐层后面。

错法对照

错法	问题	正解
治理全靠文档和口头约定	三个月后无人记得、新人无知违反	ArchUnit 等自动化校验进 CI
技术债只记录不偿还	台账变成墓碑列表	每迭代固定 20% 容量，高利息优先
为 5 人团队上 SAFe	流程开销超过产出	5 人 Kanban，15 人 Scrum 足够
架构原则定成口号（「高内聚低耦合」）	无法执行和验证	原则要可校验：「领域层不依赖框架」
大爆炸式重构还债	业务停摆数月，风险极高	绞杀者模式逐步替换，持续交付价值

卡点急救

1. 团队绕过评审直接上线：不要先追责，先看流程——是不是评审周期太长（超过 2 天就是流程问题）？把评审改成异步（PR + 24 小时静默期），重审必要性。
2. 技术债排期永远被业务需求挤掉：把债务翻译成业务语言汇报（「不还 TD-04，Redis 挂了全站课程页 500，预计每月发生 1 次」），并争取「每迭代 20%」的明文约定。
3. ADR 写了没人看：把 ADR 链接放进相关代码包的 README 和架构图注释里；新人 Onboarding 清单里列「必读 ADR Top 5」。

面试常问

• 什么是技术债？怎么管理？ 定义：为了短期交付速度而做的、已知会增加未来成本的技术妥协。分类：有意 prudent（赶窗口主动借）、有意 reckless（懒得做好）、无意（当初认知不足）。管理四步：1) 台账可见（记录本金和利息）；2) 翻译业务语言向管理层汇报；3) 固定容量偿还（每迭代 15-20%）；4) 新债准入评审（新债必须有偿还计划）。金句：「技术债失控的标志不是欠得多，而是没人知道欠了多少。」

• 怎么保证架构设计在开发过程中不走样？ 三层答：1) 代码层：ArchUnit 分层校验、契约测试（Spring Cloud Contract）进 CI；2) 流程层：ADR 决策留痕、架构评审、设计文档模板；3) 度量层：适应度函数监控关键指标（耦合度、循环依赖数），趋势劣化时预警。核心思想：把架构约束从「人的记忆」转移到「机器的校验」。

• Scrum 在实际落地中最常变形的是什么？ 三个典型变形：1) 站会变成汇报会（应该同步障碍，不是向领导汇报）；2) Sprint 内随意加需求（破坏承诺，需要 PO 守门）；3) 回顾会流于形式（改进项无人跟进，下次还犯）。补充：成熟的团队往往会从 Scrum 演化到 Kanban——仪式做减法，流动做加法。

自测三问

1. 本站的「新服务准入 checklist」应该包含哪 5 项？
2. 技术债的「本金」和「利息」分别指什么？为什么优先还高利息低本金的？
3. 为什么 ArchUnit 比架构文档更能保证架构不走样？

小结一句话

架构治理的本质是把一致性从「靠自觉」变成「靠机制」：原则要可校验、决策要留痕、债务要有台账、流程要匹配团队规模。

延伸

• 《演进式架构》（Building Evolutionary Architectures）——适应度函数思想来源
• TOGAF Standard 10（官网免费版，看 ADM 章节即可）
• 《Scrum 敏捷软件开发》（Mike Cohn）
• 下一课：综合练习——为本站设计课程推荐服务，输出完整架构文档。