Arch Day 103
Arch Day 103: 架构治理 — 确保架构决策被正确执行
Arch Day 103: 架构治理 — 确保架构决策被正确执行
2026-07-11
第四阶段 - 高阶融合架构治理架构委员会技术雷达FitnessFunctionADR架构标准
日期: 2026-07-11 (Day 103) 阶段: 第四阶段 - 高阶融合 标签: #架构治理 #架构委员会 #技术雷达 #FitnessFunction #ADR #架构标准
核心概念
架构治理是"确保架构决策被正确执行"的组织能力
架构师最痛苦的事情之一：精心设计的架构方案，在实现过程中被"魔改"得面目全非。
- 你说用Event-Driven，团队偷偷用了同步调用
- 你定义了统一的API规范，三个团队写出了三种风格
- 你要求分层架构不能跨层调用，到处是快捷方式
- 你选型了统一的技术栈，有人悄悄引入了新框架
架构治理就是解决这个问题的系统性方法——通过组织结构、流程、工具和度量，确保架构意图被正确理解和执行。
架构治理的核心悖论：
太严格 → 创新窒息、团队抱怨、绕过规则
太宽松 → 架构腐化、技术债堆积、系统混乱
目标: "Just Right" — Goldilocks治理模型
（源自ThoughtWorks《Building Evolutionary Architectures》）
2025-2026年架构治理的新挑战：
AI编码助手（Copilot等）让代码生成速度加快了20-50%，但如果没有治理，也意味着"写出不符合架构规范的代码"的速度也加快了20-50%。架构治理需要跟上AI时代的开发速度。
知识点详解
一、架构治理框架
治理四层模型
┌──────────────────────────────────────┐
│ 组织层 (Organization) │
│ 架构委员会、角色与职责、决策机制 │
├──────────────────────────────────────┤
│ 流程层 (Process) │
│ 评审流程、准入规则、例外处理 │
├──────────────────────────────────────┤
│ 工具层 (Tooling) │
│ 自动化检查、CI门禁、Fitness Functions│
├──────────────────────────────────────┤
│ 度量层 (Metrics) │
│ 合规率、技术债、架构健康度 │
└──────────────────────────────────────┘
治理成熟度模型
| 级别 | 状态 | 描述 | 典型问题 |
|---|---|---|---|
| Level 0 | 无治理 | 没有统一的架构规范 | 技术栈混乱、重复造轮子 |
| Level 1 | 事后检查 | 有规范但靠人工审查 | 发现时已来不及修复 |
| Level 2 | 流程驱动 | 有评审流程和检查点 | 流程缓慢，成为瓶颈 |
| Level 3 | 自动化治理 | CI门禁+Fitness Functions | 自动发现违规 |
| Level 4 | 演进式治理 | 数据驱动+持续改进 | 治理规则本身也在演进 |
二、架构委员会运作
组成
架构委员会（Architecture Review Board / ARB）:
角色组成:
├── 首席架构师（Chair）: 主持会议，最终决策
├── 领域架构师（Domain Architects）: 各业务域代表
│ ├── 支付域架构师
│ ├── 用户域架构师
│ └── 数据域架构师
├── 基础设施架构师: 云/运维视角
├── 安全架构师: 安全合规视角
├── 工程效能负责人: 开发体验视角
└── 轮值成员: 资深开发者轮值参与（保证接地气）
职责
核心职责:
├── 技术选型决策（新技术的引入和淘汰）
├── 架构设计评审（重大系统变更）
├── 架构标准制定（API规范/编码规范/安全基线）
├── 技术债管理（评估和优先级排序）
├── 技术雷达维护（技术选型指南）
└── 架构咨询（为团队提供架构建议）
不是职责:
├── 不做具体的代码Review（那是团队Tech Lead的事）
├── 不做日常技术决策（不micromanage）
├── 不阻碍创新（不是"技术审查部门"）
└── 不替代团队决策（赋能而非控制）
会议频率与机制
会议类型:
├── 周例会（1小时）:
│ ├── 待评审的架构提案快速过审
│ ├── 技术债月度报告（季度详细）
│ └── 行动项跟踪
│
├── 月度深度会议（2小时）:
│ ├── 重大架构决策讨论
│ ├── 技术雷达更新
│ └── 跨团队架构问题协调
│
└── 季度战略会议（半天）:
├── 技术战略对齐
├── 架构路线图审视
└── 技术债总量评估
决策机制:
├── 小决策（标准范围内）: 域架构师直接决策
├── 中决策（跨域影响）: 架构委员会讨论，多数同意
├── 大决策（全局影响）: 架构委员会+CTO决策
└── 紧急决策: 首席架构师+相关方快速决策→下次会议追认
如何避免成为瓶颈？
这是架构委员会最常见的问题——团队抱怨"每个决策都要过ARB，太慢了"。
避免成为瓶颈的策略:
1. 明确边界（什么需要过ARB）:
├── 需要: 新技术引入、重大架构变更、跨域设计
└── 不需要: 域内设计细节、工具选择（已在雷达Adopt中的）
2. 异步评审优先:
├── 提交RFC/ADR文档
├── 委员会成员异步评论（3个工作日内）
├── 无争议 → 自动通过
└── 有争议 → 上会讨论
3. 预审机制:
├── 架构师1对1与提案方沟通
├── 大部分问题在预审阶段解决
└── 正式评审变成"确认"而非"讨论"
4. 赋能而非控制:
├── 提供架构模板和参考实现
├── 定期架构培训
└── 把标准变成可复用的"架构starter kit"
三、技术雷达
ThoughtWorks技术雷达模式
ThoughtWorks Technology Radar是技术治理的标杆工具，它将技术分为四个环：
Adopt（采纳）
│
│ 经过验证，推荐广泛使用
│
Trial（试验）
│
│ 值得追求，低风险项目先试
│
Assess（评估）
│
│ 值得了解，但还需调研
│
Hold（暂缓）
│
│ 不推荐使用（或停止使用）
构建组织级技术雷达
技术雷达的四个象限:
├── 技术 (Techniques)
│ ├── Adopt: 微服务、DDD、Event Sourcing
│ ├── Trial: AI辅助开发、eBPF可观测性
│ ├── Assess: WebAssembly后端
│ └── Hold: 大型单体应用
│
├── 平台 (Platforms)
│ ├── Adopt: Kubernetes、AWS/Azure
│ ├── Trial: Backstage (IDP)、WasmEdge
│ ├── Assess: Unikernels
│ └── Hold: 自建虚拟化平台
│
├── 工具 (Tools)
│ ├── Adopt: Terraform、ArgoCD、Prometheus
│ ├── Trial: AI Code Review工具、OpenTelemetry
│ ├── Assess: AI测试生成工具
│ └── Hold: Jenkins (迁移到GitHub Actions)
│
└── 语言与框架 (Languages & Frameworks)
├── Adopt: TypeScript、Go、Spring Boot
├── Trial: Rust (系统级)、Astro
├── Assess: Zig、Mojo
└── Hold: jQuery、Struts
技术雷达维护流程
季度更新流程:
1. 收集提案（所有工程师都可提交）
└── "我建议将X从Trial移到Adopt，因为..."
└── "我建议将Y加入Assess，因为..."
2. 架构委员会评估
├── 每个提案由至少2位委员评审
├── 需要有实际使用经验的团队背书
└── 考虑维护成本和学习曲线
3. 发布更新
├── 全公司公告
├── 更新内部文档
└── 配套培训（对于新Adopt的技术）
4. 与治理流程联动
├── Adopt的技术: 自由使用
├── Trial的技术: 需域架构师批准
├── Assess的技术: 需架构委员会批准（只能用于研究项目）
└── Hold的技术: 不允许新项目使用，存量制定迁移计划
2025年ThoughtWorks技术雷达关键发现
根据2025年4月发布的第32期技术雷达：
- 生成式AI和大语言模型主导了多个象限，聚焦于负责任地在软件开发中使用AI
- AI编码工具快速演进——从简单补全到整合开发流程
- AI生态工具爆发——包括guardrails、评估框架和向量数据库
- 平台工程持续走热——内部开发者平台成为组织标配
四、架构合规自动化
Fitness Functions（架构适应度函数）
这个概念借自进化计算——用函数来衡量设计方案离目标有多近。在架构中，Fitness Function是自动化检查架构是否符合预期的机制。
Fitness Function类型:
1. 静态Fitness Functions（编译时/构建时）
├── 依赖检查: 模块间的依赖关系是否符合规则
├── 代码度量: 圈复杂度、耦合度是否在阈值内
└── 命名规范: 包名、类名是否符合约定
2. 动态Fitness Functions（运行时）
├── 性能指标: P99延迟是否 < 500ms
├── 可用性: 服务可用性是否 > 99.95%
└── 资源使用: CPU/内存是否在预算内
3. 时序Fitness Functions（时间维度）
├── 技术债趋势: 是否在持续增长
├── 依赖版本: 是否有过时的依赖
└── 安全漏洞: 新漏洞数量趋势
ArchUnit（Java架构测试）
// ArchUnit: 用代码表达架构规则
@AnalyzeClasses(packages = "com.example.payment")
public class ArchitectureRulesTest {
// 规则1: 分层架构——Controller不能直接调用Repository
@ArchTest
static final ArchRule layered_architecture =
layeredArchitecture()
.consideringAllDependencies()
.layer("Controller").definedBy("..controller..")
.layer("Service").definedBy("..service..")
.layer("Repository").definedBy("..repository..")
.whereLayer("Controller").mayOnlyAccessLayers("Service")
.whereLayer("Service").mayOnlyAccessLayers("Repository")
.whereLayer("Repository").mayNotAccessAnyLayer();
// 规则2: 领域模型不能依赖基础设施
@ArchTest
static final ArchRule domain_independence =
noClasses().that().resideInAPackage("..domain..")
.should().dependOnClassesThat()
.resideInAnyPackage("..infrastructure..", "..controller..");
// 规则3: 所有Service必须有接口
@ArchTest
static final ArchRule services_should_have_interfaces =
classes().that().resideInAPackage("..service..")
.and().haveSimpleNameEndingWith("ServiceImpl")
.should().implement(
classes().that().haveSimpleNameEndingWith("Service")
);
// 规则4: 禁止循环依赖
@ArchTest
static final ArchRule no_cycles =
slices().matching("com.example.payment.(*)..")
.should().beFreeOfCycles();
// 规则5: 所有REST Controller必须有安全注解
@ArchTest
static final ArchRule controllers_must_be_secured =
classes().that().areAnnotatedWith(RestController.class)
.should().beAnnotatedWith(Secured.class)
.orShould().beAnnotatedWith(PreAuthorize.class);
}
依赖规则（CI门禁）
# .architecture-rules.yml
rules:
# 模块依赖规则
dependencies:
- module: "payment-service"
allowed_dependencies:
- "common-lib"
- "security-lib"
- "event-lib"
forbidden_dependencies:
- "user-service" # 不允许直接依赖用户服务
- "order-service" # 必须通过事件通信
# 包依赖规则
package_rules:
- pattern: "*.domain.*"
cannot_depend_on:
- "*.infrastructure.*"
- "*.controller.*"
- "org.springframework.*" # 领域层不依赖Spring
# 第三方依赖规则
third_party:
- name: "log4j"
status: "banned" # 安全风险
alternative: "logback"
- name: "junit:junit:4.*"
status: "deprecated"
alternative: "org.junit.jupiter:*"
# CI门禁配置
ci_gates:
architecture_check:
enabled: true
blocking: true # 不通过则CI失败
checks:
- archunit_tests
- dependency_rules
- code_metrics
thresholds:
cyclomatic_complexity_max: 15
coupling_max: 0.7
code_duplication_max: 3%
五、架构标准体系
编码规范
编码规范层次:
├── 语言级规范（通过Linter自动化）
│ ├── ESLint (TypeScript/JavaScript)
│ ├── Checkstyle/SpotBugs (Java)
│ └── golangci-lint (Go)
│
├── 项目级规范
│ ├── 命名约定（类名/方法名/变量名）
│ ├── 错误处理模式
│ ├── 日志规范（级别/格式/敏感信息脱敏）
│ └── 注释规范（公共API必须注释）
│
└── 架构级规范
├── 分层调用规则
├── 依赖注入模式
├── 事件发布/订阅模式
└── 配置管理模式
API规范
api_standards:
naming:
path_style: "kebab-case" # /user-profiles
resource_naming: "plural nouns" # /users, /orders
query_params: "snake_case"
versioning:
strategy: "url_path" # /v1/...
minimum_support_period: "12 months"
sunset_header: true
response_format:
success: { code: "string", data: "object", request_id: "string" }
error: { code: "string", message: "string", details: "array" }
pagination: "cursor-based"
authentication:
internal: "JWT (short-lived)"
external: "OAuth 2.0 + PKCE"
sensitive_operations: "HMAC-SHA256"
rate_limiting:
header_prefix: "X-RateLimit-"
error_code: 429
retry_after_header: true
documentation:
format: "OpenAPI 3.1"
required_fields: [summary, description, examples, error_codes]
auto_generated: true
安全基线
security_baseline:
authentication:
- password_min_length: 12
- mfa_required: true
- session_timeout: "30 minutes"
- jwt_expiry: "15 minutes"
data_protection:
- encryption_at_rest: "AES-256"
- encryption_in_transit: "TLS 1.3"
- pii_masking: true
- log_sanitization: true
infrastructure:
- no_public_s3_buckets: true
- security_groups_least_privilege: true
- vpc_flow_logs: true
- container_image_scanning: true
development:
- no_hardcoded_secrets: true
- dependency_vulnerability_check: true
- sast_scan: true
- code_review_required: true
部署规范
deployment_standards:
container:
base_image: "approved-base-images-only"
health_check: "required"
resource_limits: "required"
non_root_user: "required"
kubernetes:
namespace_per_service: true
resource_quota: "required"
network_policy: "required"
pod_disruption_budget: "required"
release:
strategy: "canary (default) or blue-green"
canary_percentage: "5% → 20% → 50% → 100%"
auto_rollback: true
rollback_trigger:
- error_rate: "> 1%"
- latency_p99: "> 2x baseline"
observability:
structured_logging: "required (JSON format)"
metrics: "Prometheus format"
tracing: "OpenTelemetry"
sla_dashboard: "required"
六、ADR（Architecture Decision Records）体系回顾与组织级推广
ADR模板
# ADR-{number}: {标题}
## 状态
Proposed / Accepted / Deprecated / Superseded by ADR-{number}
## 日期
2026-07-11
## 上下文
什么背景导致我们需要做这个决策？
- 业务需求是什么？
- 技术约束是什么？
- 当前的痛点是什么？
## 考虑的方案
### 方案A: {名称}
- 优点: ...
- 缺点: ...
- 适用性: ...
### 方案B: {名称}
- 优点: ...
- 缺点: ...
- 适用性: ...
## 决策
我们选择方案{X}，因为...
## 影响
- 对系统的影响: ...
- 对团队的影响: ...
- 需要的投资: ...
- 风险: ...
## 合规检查
- [ ] 是否符合技术雷达？
- [ ] 是否符合安全基线？
- [ ] 是否需要架构委员会审批？
## 审批
- 提案人: @xxx
- 审批人: @xxx, @xxx
- 审批日期: 2026-07-11
组织级ADR推广策略
ADR推广路径:
1. 个人级: 架构师记录自己的决策（习惯养成）
2. 团队级: 团队内共享ADR，作为Tech Spec的一部分
3. 项目级: ADR存放在项目仓库中，随代码版本管理
4. 组织级: 中央ADR库，所有项目可搜索和引用
└── 搜索"消息队列选型" → 查看所有相关ADR和最终决策
组织级ADR治理:
├── 必须写ADR的场景:
│ ├── 引入新技术/框架
│ ├── 修改核心架构
│ ├── 选择第三方服务
│ └── 改变部署策略
│
├── ADR质量检查:
│ ├── 是否包含多个备选方案
│ ├── 是否有明确的决策理由
│ ├── 是否评估了风险和影响
│ └── 是否有审批记录
│
└── ADR可发现性:
├── 统一的编号和标签系统
├── 全文搜索功能
└── 与技术雷达联动
对比分析
治理模式对比
| 模式 | 控制度 | 灵活度 | 适用 | 风险 |
|---|---|---|---|---|
| 命令式 | 最高 | 最低 | 强合规行业 | 创新窒息 |
| 引导式 | 中高 | 中 | 大多数企业 | 执行不到位 |
| 自服务式 | 低 | 最高 | 创新型组织 | 架构腐化 |
| 演进式 | 自适应 | 自适应 | 成熟组织 | 需要高能力团队 |
Goldilocks治理模型
控制 ←──────────────────────→ 自由
│ │
命令式治理 │ ┌──────────┐ │ 无治理
(窒息创新) │ │ Goldilocks│ │ (混乱)
│ │ Zone │ │
│ │ "刚刚好" │ │
│ └──────────┘ │
│ │
在Goldilocks Zone中:
├── 有明确的原则和标准
├── 有自动化的合规检查
├── 但团队有选择实现方式的自由
├── 新技术有引入路径（Trial→Adopt）
└── 例外有处理机制（不是一刀切）
架构设计实操：设计完整"架构治理"制度文档
1. 组织设计
architecture_governance:
organization:
architecture_review_board:
chair: "首席架构师"
members:
- role: "领域架构师"
count: 3-5
responsibility: "各业务域架构决策"
- role: "基础设施架构师"
count: 1
responsibility: "云/运维架构"
- role: "安全架构师"
count: 1
responsibility: "安全合规"
- role: "轮值工程师"
count: 2
rotation: "每季度轮换"
responsibility: "保持接地气"
meeting_cadence:
weekly: "1h - 快速评审 + 跟踪"
monthly: "2h - 深度讨论 + 雷达更新"
quarterly: "4h - 战略对齐 + 技术债评估"
decision_authority:
team_level: "域内技术细节"
domain_level: "跨团队影响的设计"
board_level: "新技术引入/重大架构变更"
cto_level: "全局影响的战略决策"
2. 流程设计
processes:
architecture_review:
triggers:
- "引入新技术或框架"
- "修改核心架构设计"
- "跨域系统集成"
- "重大性能/安全变更"
flow:
1_proposal:
action: "提交ADR文档"
template: "architecture-decision-template.md"
minimum_content: [context, options, decision, impact]
2_async_review:
duration: "3个工作日"
reviewers: "至少2位架构委员会成员"
outcome:
approved: "无争议 → 自动通过"
discussion_needed: "有争议 → 上会讨论"
3_meeting_review:
only_if: "有争议或重大决策"
duration: "30分钟/提案"
output: "决策 + ADR更新 + 行动项"
exceptions:
emergency_change:
approval: "首席架构师快速审批"
post_review: "下次周例会追认"
documentation: "事后补充ADR"
tech_radar_update:
frequency: "每季度"
input: "团队提案 + 行业趋势 + 实践经验"
output: "更新后的技术雷达 + 配套培训计划"
tech_debt_review:
frequency: "每月（简要）/ 每季度（深度）"
input: "SonarQube报告 + 团队反馈 + Fitness Function结果"
output: "技术债优先级排序 + 偿还计划"
3. 工具设计
tooling:
automated_checks:
ci_gates:
- name: "ArchUnit Tests"
stage: "build"
blocking: true
checks:
- "分层依赖规则"
- "循环依赖检查"
- "命名规范检查"
- name: "Dependency Check"
stage: "build"
blocking: true
checks:
- "禁用依赖检查"
- "版本漏洞扫描"
- "License合规检查"
- name: "API Spec Validation"
stage: "build"
blocking: true
checks:
- "OpenAPI规范校验"
- "Breaking Change检测"
- "命名规范检查"
- name: "Security Baseline"
stage: "build"
blocking: true
checks:
- "SAST扫描"
- "密钥泄露检测"
- "容器安全扫描"
runtime_checks:
- name: "Performance Fitness"
metric: "p99_latency"
threshold: "< 500ms"
alert: true
- name: "Availability Fitness"
metric: "success_rate"
threshold: "> 99.95%"
alert: true
- name: "Dependency Freshness"
metric: "outdated_dependencies_count"
threshold: "< 5"
frequency: "weekly"
platforms:
adr_management: "在Git仓库中管理（/docs/adr/）"
tech_radar: "内部Wiki + 可视化工具"
architecture_diagrams: "C4 Model (Structurizr)"
fitness_dashboard: "Grafana + 自定义面板"
4. 度量设计
metrics:
compliance_metrics:
- name: "架构规则通过率"
formula: "通过CI门禁的PR数 / 总PR数"
target: "> 95%"
trend: "月度趋势"
- name: "ADR覆盖率"
formula: "有ADR的架构决策数 / 总架构决策数"
target: "> 90%"
- name: "技术雷达合规率"
formula: "使用Adopt/Trial技术的项目 / 总项目"
target: "> 85%"
health_metrics:
- name: "技术债指数"
source: "SonarQube"
target: "< 5天（修复成本）"
trend: "不应持续增长"
- name: "依赖新鲜度"
formula: "使用最新主版本的依赖 / 总依赖"
target: "> 80%"
- name: "API规范符合率"
formula: "符合规范的API / 总API"
target: "> 95%"
process_metrics:
- name: "评审周期"
formula: "从提交到决策的平均时间"
target: "< 5个工作日"
alert_if: "> 10个工作日" # 防止成为瓶颈
- name: "例外处理比例"
formula: "走例外流程的决策 / 总决策"
target: "< 10%"
alert_if: "> 20%" # 说明标准不合理
AI增强
AI如何改变架构治理
-
AI辅助架构评审：
- LLM自动审查ADR文档的完整性和逻辑性
- 根据历史ADR推荐相似案例和决策模式
- 自动识别架构设计中的潜在风险
-
AI驱动的Fitness Functions：
- AI分析代码变更，预测是否可能违反架构规则
- 动态调整Fitness Function阈值（基于历史数据）
- 自动生成新的Fitness Function建议
-
智能技术雷达：
- AI扫描行业趋势，自动推荐技术雷达更新
- 分析组织内技术使用数据，生成"实际技术雷达"
- 预测技术趋势（哪些技术即将被淘汰）
-
AI编码合规：
- 在开发者编写代码时实时提示架构规范
- AI代码审查自动标记不符合架构规则的代码
- 自动生成符合架构规范的代码模板
应对AI时代的治理挑战
2025-2026年，AI编码助手让代码产出速度提升了20-50%。架构治理必须适应这个变化：
挑战: AI生成的代码可能不符合架构规范
应对:
├── 将架构规则编码为AI助手的上下文（Prompt Engineering）
├── CI门禁中的Fitness Functions是最后防线
├── AI Code Review自动检查架构合规性
└── 定期审计AI生成代码的架构符合度
Web3关联
DeFi协议的"架构治理"
Web3项目也面临架构治理挑战，但形式不同：
- 智能合约不可变性：一旦部署就无法修改，架构决策的代价更高
- DAO治理：协议升级需要社区投票——相当于"架构委员会是全体持币者"
- ERC标准：类似"架构标准体系"，定义接口规范（ERC-20/721/1155）
- 审计报告：类似"架构评审"，但由第三方安全审计公司执行
Web3的启示：架构治理应该透明、可验证、有社区参与。传统企业可以借鉴Web3的治理透明度。
今日思考
架构治理的核心挑战是在"控制"和"自由"之间找到平衡。ThoughtWorks的Goldilocks模型给出了方向——不是管多管少的问题，而是管什么、怎么管的问题。
2025-2026年的关键变化：
- 自动化是治理的基石——人工审查无法跟上AI时代的代码产出速度
- Fitness Functions让架构规则可验证——不是"写在文档里没人看"，而是"CI不通过就不能部署"
- 技术雷达让技术选型有据可依——不是"老板说用什么就用什么"，而是有数据和经验支撑
- ADR让决策可追溯——不是"为什么这么设计？不知道，前任走了"
架构治理不是目的，而是手段。最终目标是让架构能够持续演进，同时保持一致性和质量。
面试题
Q1: 如何建立架构治理体系？
30秒回答：四层体系——组织层（架构委员会+角色职责）、流程层（评审流程+例外处理）、工具层（CI门禁+Fitness Functions+ArchUnit）、度量层（合规率+技术债指数+评审周期）。关键是自动化治理，避免成为瓶颈。
2分钟详细回答：
建立架构治理体系需要循序渐进：
阶段1（1-2月）：建立基础
- 成立架构委员会，明确角色和职责
- 制定核心架构标准（API规范/安全基线/部署规范）
- 引入ADR机制，记录重大架构决策
阶段2（3-4月）：流程自动化
- 在CI中集成ArchUnit等架构测试
- 建立依赖规则和代码质量门禁
- 发布第一版技术雷达
阶段3（5-6月）：持续改进
- 建立度量体系，跟踪合规率和技术债
- 引入Fitness Functions做运行时检查
- 建立反馈机制，持续优化治理规则
关键成功因素：获得CTO支持、以赋能而非控制为导向、大量自动化减少人工负担。
追问准备：
- 团队抵制架构治理怎么办？→ 从自动化检查开始（不增加工作量），展示治理的价值（减少返工/事故）
- 如何衡量治理效果？→ CI门禁通过率、架构评审周期、技术债趋势
Q2: 架构委员会如何避免成为瓶颈？
30秒回答：三个策略——明确边界（只审重大决策，域内细节由团队自主）、异步优先（ADR文档异步评审，无争议自动通过）、赋能导向（提供架构模板和参考实现，让团队自助服务）。
2分钟详细回答：
架构委员会成为瓶颈通常是因为"管太多"或"流程太重"。解决方案：
- 明确评审边界：新技术引入/跨域设计需要评审，域内细节/已批准技术的使用不需要
- 异步评审优先：大部分提案通过ADR文档异步评审，3天内无反对则自动通过。只有有争议的才上会
- 预审机制：架构师与提案方1对1沟通，大部分问题在预审解决，正式评审变成确认
- 自服务工具：提供架构Starter Kit、参考实现、最佳实践库，让团队自助满足大部分需求
- 度量监控：跟踪评审周期（目标<5天），超过10天触发告警改进流程
学习资源
- ThoughtWorks Technology Radar — 技术雷达最新版
- ThoughtWorks Technology Radar Vol 32 PDF — 2025年4月第32期
- Using Tech Radar for Governance | ThoughtWorks — 技术雷达治理实践
- Architectural Governance | ThoughtWorks Podcast — 架构治理播客
- Fitness Functions | ThoughtWorks — Fitness Function详解
- ArchUnit — Java架构测试框架
- 4 Things from Latest TW Radar | LeadDev — 最新雷达解读
明日预告
明天我们将进入遗留系统改造——"在飞行中换引擎"，最难的架构挑战之一。我们将深入学习绞杀者模式（Strangler Fig Pattern）、防腐层（Anti-Corruption Layer）设计、渐进式数据迁移策略，以及遗留系统改造中最大的挑战——组织和政治因素。