软件开发领域的架构设计长期存在两个典型极端，几乎每个有经验的开发者都经历过这两者的痛苦。
团队投入大量时间绘制精美的架构图、编写详细的架构文档、定义严格的技术规范，但项目本身只有很少的未知风险。
典型症状：
过度设计的成本：
| 成本类型 | 具体表现 | 量化估算 |
|---|---|---|
| 机会成本 | 本该做业务功能的时间用在架构上 | 每个迭代浪费 20-40% 产能 |
| 认知负荷 | 新成员需要消化大量架构文档才能上手 | 新人的 ramp-up 时间从2周延长到6周 |
| 维护成本 | 抽象层越多，理解链路越长 | 每次修改要遍历 3-5 层才能找到实际影响点 |
| 变更阻力 | 过度抽象的接口让简单变更变得困难 | 一次简单的字段添加需要修改 4 个接口定义 + 2 个转换层 |
团队忽视架构设计，直接进入编码，把所有"架构性的东西"留到"以后再说"。
典型症状：
设计不足的成本：
| 成本类型 | 具体表现 | 量化估算 |
|---|---|---|
| 重构成本 | 需要修改核心模块以支撑新需求 | 随着系统增长，重构难度呈指数上升 |
| 运维成本 | 缺乏监控、容错、降级等机制 | 每次线上事故的排查时间增加 3-5 倍 |
| 团队士气 | 在混乱的代码库中开发，疲劳感强 | 三个月后核心成员流失风险显著增加 |
| 业务损失 | 系统不稳定导致用户流失 | 一次严重故障可能导致 5-10% 的日活下降 |
这两个极端之间的张力其实指向一个根本问题："到底需要做多少架构设计？"
传统方法论的回答往往是模糊的：
George Fairbanks 用一个简单但深刻的框架回答了这个问题：风险驱动模型（Risk-Driven Model，RDM）。
核心答案：架构工作的深度和广度应当与项目的真实风险向匹配。不多一分，不少一毫。
RDM 的核心是一个简洁的三步循环：
┌─────────────────┐
│ ① 识别风险 │
│ Identify Risks │
└────────┬────────┘
↓
┌─────────────────┐ ┌─────────────────┐
│ ② 选择应对策略 │────>│ ③ 验证应对效果 │
│ Mitigate Risks │ │ Validate │
└─────────────────┘ └────────┬────────┘
↑ │
└───────────────────────┘
(循环，直到所有高优先级风险得到处理)
RDM 最核心的洞见是：不是所有的架构活动都创造同等价值。只有直接应对特定风险的架构活动才是有价值的。没有风险的架构活动——无论它看起来多么"规范"——本质上是浪费。
类比一下：你会在晴天出行前给车换上雪地胎吗？不会，因为没有雪地打滑的风险。但如果你要在下雪天翻越雪山，不换雪地胎就是不负责任。同样一个行动，在不同的风险环境下价值完全不同。
RDM 对架构风险给出了明确的定义：
架构风险 = 系统在某个质量属性上未能达标的可能性 × 该失效的影响程度
更具体地说，架构风险关注的是非功能需求的失效可能性：
| 风险类别 | 质量属性 | 典型提问 | 影响评估维度 |
|---|---|---|---|
| 性能 | 响应时间、吞吐量 | "系统能否在并发 2000 时 3 秒内响应？" | 用户体验、业务转化率 |
| 安全 | 机密性、完整性、可用性 | "用户数据是否可能被未授权访问？" | 合规罚款、品牌声誉 |
| 可用性 | 故障恢复、服务连续性 | "数据库故障时系统能否继续为用户服务？" | 业务中断时长 |
| 可维护性 | 可理解性、可修改性 | "更换支付服务商需要修改多少代码？" | 功能交付速度 |
| 可扩展性 | 容量增长能力 | "用户从 1 万增长到 100 万时架构能支撑吗？" | 业务增长天花板 |
| 可测试性 | 可观察性、可控制性 | "如何验证分布式事务的正确性？" | 质量保障成本 |
| 可靠性 | 容错能力、一致性 | "服务 A 调用服务 B 失败时，数据是否一致？" | 数据质量、业务准确度 |
| 可部署性 | 部署独立性、回滚能力 | "能否在不影响其他功能的情况下发布新版本？" | 发布频率与安全 |
通过系统化的场景分析识别风险。可以参考 ATAM（Architecture Tradeoff Analysis Method）的场景模板：
场景 = 刺激源 + 刺激 + 环境 + 制品 + 响应 + 响应度量
示例场景：
**场景：高并发下的订单创建**
- 刺激源：营销活动带来的大量用户
- 刺激：10,000 个用户同时发起下单请求
- 环境：正常运行的生产环境
- 制品：订单系统
- 响应：系统正确处理所有订单请求
- 响应度量：P99 响应时间 < 2 秒，无订单丢失
通过场景分析，可以系统化地发现以下类型的风险：
正常操作场景风险：系统在日常负载下能否正常工作？
峰值场景风险：系统在极端负载下是否还能维持核心功能？
异常场景风险：系统在故障情况下的行为是否符合预期？
演进场景风险：系统在未来变化中的适应能力如何？
很多时候，架构风险来自于"没有做决定"的决定——隐式的架构决策可能引入未知风险。
常见的隐式决策及其风险：
| 场景 | 隐式决策 | 隐含风险 |
|---|---|---|
| 选了 MySQL，认为 "够用就行" | 数据存储在单库，无读写分离 | 未来写瓶颈时，拆分成本极高 |
| 用 REST API 通信，认为 "简单" | 同步调用，串行链路 | 下游服务故障会导致上游超时雪崩 |
| 用 JSON 序列化，认为 "通用" | 无 schema 约束 | 接口变更难以发现，缺乏契约测试 |
| 不用消息队列，认为 "没必要" | 同步处理所有请求 | 突发流量时无法削峰，系统可能被压垮 |
实操方法：
在每个迭代结束时，开一个 30 分钟的"架构决策审计"会议：
以下是基于大量项目实践总结的高频风险清单。每个项目可以从中选取自己适用的项，也可以持续补充：
业务风险：
技术风险：
组织风险：
演进风险：
识别出风险后，需要对风险进行排序，确定优先处理的顺序。常用的是"影响 × 概率"矩阵：
概率
低 中 高
┌─────┬──────┬──────┐
高 │ 中 │ 高 │ 高 │
├─────┼──────┼──────┤
影响 中 │ 低 │ 中 │ 高 │
├─────┼──────┼──────┤
低 │ 低 │ 低 │ 中 │
└─────┴──────┴──────┘
处理优先级：高 > 中 > 低
实操建议：
识别出风险并排序后，可以选择以下策略：
| 策略 | 说明 | 适用场景 | 架构投入 |
|---|---|---|---|
| 接受 | 不做任何防备，承认风险存在，承担后果 | 影响小、概率低的风险 | 零 |
| 缓解 | 通过架构手段降低风险的概率或影响 | 高风险但可通过技术手段控制 | 中等-高 |
| 转移 | 将风险的后果转移到第三方（如购买云服务、外包） | 自身能力不具备的风控领域 | 低（但有持续成本） |
| 避免 | 修改需求或设计，消除风险源 | 风险极高且无法通过其他手段控制 | 低-中 |
关键原则：只有在"缓解"策略下才需要投入架构工作。接受、转移、避免都需要极少的架构投入。
Fairbanks 在书中深入讨论了"模型"在架构设计中的角色。这不是一个学术性的讨论，而是非常实用的指导——模型做得过多是浪费，做得过少是隐患。
定义：概念模型是团队对系统如何工作的共享理解。
这个概念决定了：
概念模型的三种存在形式：
| 形式 | 示例 | 持久性 | 适合场景 |
|---|---|---|---|
| 口头 | 白板讨论、设计评审 | 低（说完了就忘） | 3人以下小团队，高频沟通 |
| 轻量文档 | 几个关键图 + 一段话描述 | 中（需要维护） | 4-9人团队，需要基础设施 |
| 正式文档 | 架构决策记录（ADR）+ 架构图 | 高（正式归档） | 10+人团队，多地协作 |
关键洞察：概念模型不需要完美的表达——只要团队对系统的理解一致，模型就完成了它的使命。
实操案例：
一个 5 人团队在讨论新系统的缓存策略：
在没有概念模型的情况下：
- A："用 Redis 缓存用户信息"
- B："对，缓存数据"
- C："那用户登录后的 Session 呢？"
结果：A 说的是"页面数据缓存"，B 想的是"数据库查询结果缓存"，C 关心的是"分布式 Session"。同一个关于"缓存"的讨论，三个人的理解完全不同。
有概念模型之后：
- 团队花 15 分钟画了一张缓存分层图
┌─────────────┐
│ CDN 缓存 │ (静态资源)
├─────────────┤
│ Redis 缓存 │ (热点数据,Session)
├─────────────┤
│ 本地缓存 │ (进程内,低频变化数据)
├─────────────┤
│ 数据库 │ (持久化存储)
└─────────────┘
- 所有后续讨论都基于这个共享的画面进行
- 15 分钟的投入节省了反复沟通和误解的代价
定义：领域模型是对问题域的抽象，描述业务概念及其关系和规则。
领域模型更侧重于业务逻辑层面而非技术实现层面。它来源于 DDD（领域驱动设计）的思想，但在 RDM 中表现得更为务实。
领域模型的核心价值：
给领域建模的投入定级：
| 业务复杂度 | 领域稳定性 | 建议投入 | 典型做法 |
|---|---|---|---|
| 简单（增删改查为主） | 稳定 | 低 | 数据库表设计即可，无需正式领域模型 |
| 中等（少量业务规则） | 略有变化 | 中 | 核心实体的领域模型 + 关键业务规则文档 |
| 复杂（丰富的业务逻辑和约束） | 频繁变化 | 高 | DDD 战略设计（限界上下文）+ 战术设计（聚合、实体、值对象） |
Fairbanks 强调：建模的深度应当由风险决定。
可以用三个问题快速决策：
Q1：如果团队对系统的理解不一致，会导致什么问题？
↓
问题严重 → 需要概念模型
问题不严重 → 口头沟通即可
Q2：如果业务逻辑理解错误，会导致多少损失？
↓
损失大 → 需要领域模型
损失小 → 代码中体现即可
Q3：模型本身需要维护的成本是否超过其带来的价值？
↓
超过 → 减少建模投入，用其他方式替代
不超过 → 保持当前投入水平
RDM 循环的第三步是验证——确认架构决策确实解决了识别的风险。这一步常被忽视，但至关重要。
水平 验证方法 确认什么
────────────────────────────────────────────────
生产层 │ APM 监控、SLA 告警 │ 线上真实表现
系统层 │ 压力测试、安全渗透测试 │ 系统的边界能力
实现层 │ 代码审查、静态分析 │ 决策是否正确实现
原型层 │ 技术原型、概念验证 │ 技术可行性
理论层 │ 架构评审、设计评审 │ 架构决策的合理性
| 层级 | 方法 | 何时做 | 发现问题后 |
|---|---|---|---|
| 理论验证 | 架构评审、同行评审 | 架构设计完成时 | 修正设计，重新评审 |
| 原型验证 | Spike、PoC、Tracer Bullet | 进入实际开发前 | 调整技术选型或设计方向 |
| 实现验证 | 代码审查、静态分析、单元测试 | 编码完成后 | 修复实现偏差 |
| 系统验证 | 性能测试、安全测试、压力测试、混沌工程 | 测试阶段 | 如果不达标，重新评估架构假设 |
| 生产验证 | 监控、告警、SLA 跟踪、APM 工具 | 上线运行期间 | 持续监控，在 SLA 触发前做预防性调整 |
RDM 要求将验证作为架构决策的一部分，而不是事后补充。每个重要的架构决策应当包含三个要素：
决策编号：ADR-2026-001
决策内容：引入 Redis 作为缓存层
风险关联：高并发场景下订单接口响应时间超过 500ms
验证方法：
- 压测验证：模拟 2000 QPS 并发请求，监控 P99 响应时间目标 < 300ms
- 命中率验证：上线一周后评估缓存命中率目标 > 85%
- 失败验证：Redis 宕机时系统能否降级为直接查库（功能降级但可用）
陷阱 1：在玩具环境中验证
只在单台服务器、小数据量下测试，得到的结论与生产环境相差甚远。
应对：至少做一次与生产环境规模相当的压测，或使用影子流量验证。
陷阱 2：验证指标的片面性
只验证了平均响应时间，忽略了 P99、P999；只验证了功能正确性，忽略了并发安全性。
应对：为每个风险设定多维度验证指标。
陷阱 3：一次验证就结束
架构验证不是一次性活动——随着系统的演进和规模的增长，原来的架构假设可能不再成立。
应对：建立持续验证机制，定期重新评估架构决策的有效性（例如每季度一次架构健康检查）。
陷阱 4：验证结果不反馈到架构
验证暴露了问题，但团队因为进度压力选择忽略。
应对：将验证发现的问题纳入产品 Backlog，给予合理的优先级，与产品功能需求一起排期处理。
RDM 不是一次性的"架构设计阶段"，而是贯穿整个项目始终的持续活动：
项目启动
│
├──→ 初始风险识别（1-2 天）
│ 产出：风险清单 + 优先处理的 Top 风险
│
├──→ 迭代 1
│ ├── 针对 Top 风险做架构设计
│ ├── 编码实现
│ └── 验证架构决策
│
├──→ 迭代 2
│ ├── 重新评估风险
│ ├── 针对新出现的风险做架构调整
│ └── ...（继续迭代）
│
└──→ ...（持续演进）
关键节奏：
| 频率 | 活动 | 参与者 | 产出 |
|---|---|---|---|
| 每天 | 架构相关的日常决策讨论 | 开发团队 | 选型记录（可选） |
| 每次迭代 | 迭代风险回顾 | 开发团队 + Tech Lead | 更新的风险清单 |
| 每季度 | 架构健康检查 | 架构组 + 技术经理 | 架构评估报告 |
| 架构决策时 | ADR 记录 | 决策者 | 架构决策记录 |
RDM 与敏捷开发天然兼容，因为它本身就是一种"刚刚好"的指导思想：
Scrum 中的 RDM：
| Scrum 活动 | RDM 实践 |
|---|---|
| Sprint Planning | 识别当前 Sprint 的架构风险，将高风险的架构任务拆分为独立的 Sprint Backlog 项 |
| Daily Standup | 快速同步架构相关进展和阻塞项 |
| Sprint Review | 展示架构验证结果（性能测试报告、安全扫描结果等） |
| Sprint Retrospective | 回顾架构风险的变化，讨论 RDM 流程是否需要调整 |
| Backlog Refinement | 识别需要架构工作的用户故事，添加架构风险标签 |
Kanban 中的 RDM：
| 团队规模 | 特点 | RDM 实施建议 | 架构角色 |
|---|---|---|---|
| 1-3 人 | 沟通成本极低，可以"心照不宣" | 白板讨论替代文档，只对严重影响业务的风险做架构设计 | 全员参与 |
| 4-9 人 | 需要适度的文档化确保理解一致 | 建立轻量级 ADR 体系，每个迭代在 Retro 中做 15 分钟风险回顾 | Tech Lead 主导 |
| 10+ 人 | 模块边界、接口契约的沟通成本高 | 需要正式的风险管理流程和架构决策流程，定期架构评审 | 架构师 + Tech Lead |
| 多团队协作 | 跨团队协调、接口兼容、集成测试成为关键风险 | 建立组织级架构治理流程，定期跨团队架构同步 | 架构组 + 各团队 Tech Lead |
适用：从零开始的新项目
优点：前期投入可控，方向明确
风险：原型探索可能变成了"正式开发"
适用：已有成熟技术栈的持续开发
优点：完全避免架构镀金
风险：可能需要频繁重构
适用：大型遗留系统演进
优点：持续改进，系统渐进式演进
风险：可能需要说服业务方为"看不到的功能"分配时间
适用：对可预测性要求高的系统（金融、医疗等）
优点：响应及时，控制严格
风险：流程可能过于重型
适用：大多数团队
优点：根据项目阶段灵活切换
风险：模式切换需要团队达成共识
Fairbanks 在书中讨论了一些常见的架构反模式，从 RDM 的视角可以更深刻地理解其成因和解决方案。
表现：在项目开始前，架构师"预见"了所有可能的需求变化，设计了一个极其通用的架构——支持多租户、支持多种数据库、支持多种部署方式……但实际只用到了最简单的单租户、单数据库、单机部署。
为什么这是个问题：
RDM 视角：
在项目启动阶段，"将来可能需要支持多租户"是一个不确定性，但不是一个需要立即应对的风险。
→ 只需要在接口设计上预留扩展点即可
→ 不需要实现完整的多租户架构
表现：在架构中加入当前需求不需要的功能或组件，理由是"未来会用到的"——用了消息队列但当前只有两个服务，不需要异步解耦；做了全面的监控告警但系统还只有 3 个用户。
为什么这是个问题：
RDM 视角：
每个架构决策都要回答："这个决策应对了什么具体的风险？"
如果回答不出与当前项目阶段对应的风险，就是镀金。
表现：团队为了追求完美的架构设计，反复讨论、频繁重构，导致真正实现的功能很少。
典型对话：
为什么这是个问题：
RDM 视角：
持续问自己：当前的架构决策是否已经足够让接下来的编码工作安全地进行？
如果是，那就接受"足够好"的架构，开始写代码。
用户的反馈比完美的架构图更有价值。
从 RDM 视角看，这些反模式有一个共同特征：架构工作与风险脱节。
解决方案：把"这个架构决策应对了什么风险"作为决策理由的必填字段。
TOGAF 是面向企业级架构的完整框架，涵盖了业务架构、数据架构、应用架构、技术架构四大领域，是"全面"的架构方法论。
RDM 聚焦于单个项目的架构风险，是"精准"的架构方法论。
| 维度 | TOGAF | RDM |
|---|---|---|
| 范围 | 整个企业 | 单个项目/系统 |
| 目标 | 战略对齐、标准化 | 风险驱动的架构决策 |
| 复杂度 | 高，需要专业团队 | 低，任何团队可实施 |
| 产出 | 全面的架构文档 | 针对性的架构决策 |
结合方式：在 TOGAF 的"解决方案架构"阶段，可以应用 RDM 来决定具体做多少架构设计。
敏捷架构强调演进式设计、小步快跑、拥抱变化。RDM 为敏捷架构提供了一个具体的决策框架——"敏捷开发中到底需要做多少架构设计？" 这个问题的答案就在 RDM 中。
共性：
互补：
| 维度 | DDD | RDM |
|---|---|---|
| 关注点 | 如何对复杂业务进行建模 | 如何分配架构投入 |
| 核心产出 | 限界上下文、聚合、实体、值对象 | 风险清单、架构决策、验证计划 |
| 适用场景 | 业务逻辑复杂的系统 | 任何有技术风险的项目 |
最佳实践：先用 RDM 评估"业务复杂度的风险"，如果该风险高，再引入 DDD 的领域建模方法。
流程示例：
步骤 1（RDM）：项目启动，识别风险 → 发现"业务规则复杂且频繁变化"被评估为高风险
步骤 2（DDD）：引入 DDD 战略设计 → 识别限界上下文、建立通用语言
步骤 3（RDM）：验证 DDD 建模是否有效降低了业务复杂度风险
| 维度 | ATAM | RDM |
|---|---|---|
| 目的 | 评估已有架构的质量属性 | 决定需要做多少架构设计 |
| 方式 | 正式评审会议 | 轻量级风险分析 |
| 参与者 | 架构师 + 利益相关者 | 开发团队内部 |
| 时间点 | 架构完成后 | 持续进行 |
结合方式：RDM 作为日常实践，ATAM 作为关键里程碑的质量把关。每季度或半年做一次正式的 ATAM 评审，平时以 RDM 方式持续管理风险。
这是一个将 RDM 从头到尾应用在真实项目中的完整案例。
团队用一天的时间做了风险识别工作坊，产出如下：
识别的风险：
风险 影响 概率 等级 策略
─────────────────────────────────────────────────────────
1. 支付系统风险 高 中 HIGH 缓解
2. 库存一致性风险 高 中 HIGH 缓解
3. 团队技能风险 中 高 HIGH 缓解
4. 高并发风险 高 低 MEDIUM 监控+准备
5. 数据增长风险 低 低 LOW 接受
分析：
风险：第三方支付接口不稳定，支付失败导致用户流失
架构决策：
验证方法：
风险：高并发下单导致超卖
架构决策：
UPDATE product SET stock = stock - 1 WHERE id = ? AND stock > 0验证方法：
风险：团队对技术栈不熟练，可能导致质量和进度风险
策略（非传统架构手段，但确实是风险应对）：
上线后 3 个月的验证结果：
| 决策 | 验证指标 | 实际结果 | 结论 |
|---|---|---|---|
| 支付异步化 | 支付成功率 > 99% | 99.7% | ✅ 有效 |
| 乐观锁库存 | 无超卖订单 | 0 起超卖 | ✅ 有效 |
| 团队提升 | 第一个 Sprint 交付率 > 80% | 85% | ✅ 有效 |
风险重评：
坑 1：把"不确定性"当作"风险"
RDM 中最常见的误用是把所有"不确定的事情"都标记为风险。但不确定性不等于风险——只有当不确定性"可能导致负面结果"时才需要应对。
例如："未来客户可能会增加 100 倍"——这是一个不确定性，但如果当前业务模式的增长预期是每年 30%，那么在短期内这不是需要架构应对的风险。
识别方法：问自己三遍"这真的会出问题吗？如果出问题了，影响有多大？"
坑 2：识别了风险，但没有转化为决策
一些团队花了很多精力做风险分析，产出了一份漂亮的风险矩阵图，然后把它存档了——没有转化为任何实际的架构决策。这就像去医院做了全身检查但没有接受治疗。
应对：每个"缓解"策略的风险，必须有对应的可执行架构决策。决策不是"我们要考虑……"，而是"我们决定……"。
坑 3：忽略了隐性风险
系统中最危险的风险往往不是那些被显式列出的，而是那些隐藏在假设中的——"PostgreSQL 肯定够用"、"这个简单，不需要测试"、"大家都熟这个框架"。
应对：在每个迭代中专门设一个环节讨论"我们正在做的假设"。
任何方法论都有边界。以下是 RDM 不适用的情况：
1. 技术探索阶段
当团队在探索一个全新的技术领域时，目标本身就不明确，无法用"风险"来衡量——就像探险家在航海，你不知道前面是陆地还是海怪。
做法：在这一阶段多投入一些"探索性原型"，即使目标不明确。RDM 可以等方向确定后再介入。
2. 平台/基础设施团队
如果你的团队是为其他团队提供服务的平台团队，你的"客户"的需求更加多样化。即使某个通用功能当前没有特定的风险关联，它可能在未来为多个业务团队节省大量时间。
做法：在平台架构中多做一些通用设计，但要用 ADR 记录决策理由，明确"做这个通用功能是为了哪些已知或预期的需求场景"。
3. 合规性要求
某些架构决策不是为了应对项目的技术风险，而是为了满足外部的合规性要求（GDPR、PCI-DSS、等保等）。这些要求是强制性的，不能通过"接受"策略绕过。
做法：将这些合规要求单独列为一个风险分类——"合规风险"。它们的优先级高于一切。
4. 学习型项目
如果项目的主要目的是团队学习新技能，而不是交付业务价值（如内部 Hackathon、技术预研），"架构投入"的标准应该放宽——多做实验、多尝试不同的方案，这对团队成长有益。
经过多年项目实践，总结出几条简单实用的经验法则：
| 场景 | 法则 |
|---|---|
| 不确定该做多少架构时 | "先写代码，发现问题再拆"——如果代码混乱得不可控了，说明架构不足 |
| 觉得架构太复杂时 | "如果图比代码难画，说明你做多了"——简化，回退到最直接的方案 |
| 决策犹豫不决时 | "让用户帮你决定"——尽快跑通完整链路收集反馈，比闭门造车好 |
| 验证周期太长时 | "先确认关键路径"——不要等所有验证做完才行动，先验证最高风险项 |
| 架构文档没人看时 | "文档是副产品，不是目标"——如果无人问津，问是否真需要它 |
一个简单的快速评估：
1. 你是否见过"设计过度但项目本身很简单"的情况？ 是 / 否
2. 你是否见过"没有架构导致系统几乎不可维护"的情况？ 是 / 否
3. 你是否经常在"要不要先做架构"这个问题上纠结？ 是 / 否
4. 你的团队是否有"应该做什么"的共识问题？ 是 / 否
如果以上任何一条答案为"是"——RDM 对你的项目有价值。
"恰如其分的软件架构"提供了一个简洁但强大的思维框架，可以用一句话概括：
识别风险 → 匹配架构投入 → 验证效果。只对需要缓解的风险做架构设计。
这个框架的优雅之处在于：
| 原则 | 含义 | 实操 |
|---|---|---|
| 风险驱动 | 架构工作的唯一正当理由是"应对风险" | 每个架构决策记录关联的风险 |
| 匹配投入 | 高风险的投入大，低风险的投入小甚至不投入 | 只对 High 风险做架构设计 |
| 持续验证 | 架构决策是否有效需要持续验证 | 建立五层验证机制 |
| 动态调整 | 风险是变化的，架构策略也需要变化 | 每个迭代重新评估风险清单 |
架构的价值不在于它有多"好"，而在于它有效地应对了项目的真实风险。
📚 读书笔记 | 架构师书架系列