风险驱动架构 = 每个架构风格缓解一个风险
一、业务问题
架构决策的常见错误：
- "CQRS 很酷，用上！"
- "微服务很火，拆！"
- "Kubernetes 流行，上！"
Vernon 在 Ch 4 明确反对这种"工具驱动"思路：
"The following architectural styles and patterns are not a grab bag of cool tools we should apply everywhere possible."
正确思路：每个架构风格 = 缓解一个特定风险。
二、控制论视角
架构风格 = 控制律的具体形式
风险 = 系统可能失败的方式
类比：
- 反馈控制 缓解 风险 = 偏差积累
- 前馈控制 缓解 风险 = 可预测干扰
- 自适应 缓解 风险 = 参数漂移
Vernon 的思路：
- 每种控制律有对应的"被缓解的风险"
- 没有风险 = 不需要该控制律钱学森 Ch 9 §9.4（最优存在性）：
"在进行控制设计时，首先重要的是搞清楚最优控制是否存在"——架构需要 justify。
软件对位：风险驱动 = 证明架构有缓解目标（"最优存在"），否则不用。
钱学森 Ch 4 §4.8（三难困境）：
"片面的追求某一个高指标会使其他的性能受到影响"——架构风格有代价。
软件对位：每种架构风格都牺牲一些（性能 vs 一致性 vs 复杂度），要按风险选择。
三、核心思想
3.1 风险驱动原则
原则：
- 架构不是炫技，是风险缓解
- 每种架构风格都对应一个风险
- 没用到的风格 = 不需要的风险
- 用错的风格 = 制造风险
- 用对的风格 = 缓解特定风险Vernon 原话：
"Allowing real, genuine quality demands to drive what we do with architecture is a beneficial risk-driven approach. That way we use architecture only to mitigate the risk of failure, not to increase our risk of failure by using an architectural style or pattern that cannot be justified."
3.2 决策流程
步骤：
1. 识别风险
2. 评估风险的影响和概率
3. 为高影响风险选架构
4. 接受低影响风险
5. 定期回顾3.3 风险与架构对照表
| 风险 | 缓解的架构 |
|---|---|
| 业务逻辑被技术细节污染 | Hexagonal / DIP |
| 读写性能冲突 | CQRS |
| 跨系统耦合 | Event-Driven |
| 单体难维护 | Layers（轻量级） |
| 团队协作混乱 | Bounded Context + Hexagonal |
| 性能要求高 | CQRS + 缓存层 |
| 业务规则复杂 | 领域服务 + Aggregates |
| 跨 BC 集成 | REST + 事件 |
四、四种主要架构风格
4.1 Layers Architecture（分层架构）
适用风险：
- 业务简单
- 团队小
- 没有特殊风险
不适用：
- 业务复杂
- 多技术栈
- 需要技术多样性4.2 Hexagonal Architecture（六边形）
适用风险：
- 业务复杂
- 多技术栈
- 需要清晰边界
- 业务逻辑被技术细节污染
特点：
- 领域在中心
- 通过 Ports + Adapters
- 技术多样性4.3 CQRS（Command Query Responsibility Segregation）
适用风险：
- 读写性能要求不同
- 业务规则复杂
- 读多写少
- 需要复杂查询
特点：
- 读写分离
- 通过事件同步
- 性能优化4.4 Event-Driven Architecture
适用风险：
- 跨系统集成
- 异步业务流程
- 跨 BC 协调
- 故障隔离
特点：
- 事件总线
- 异步处理
- 最终一致五、工程实践
实战 1：风险评估
步骤：
1. 列出可能的风险
2. 评估每个风险的影响（高/中/低）
3. 评估每个风险的概率（高/中/低）
4. 影响 × 概率 = 风险评分
5. 高分风险必须缓解
例：
风险1：业务复杂（高影响 + 中概率）→ 选 Hexagonal
风险2：性能要求高（中影响 + 中概率）→ 选 CQRS
风险3：跨团队集成（中影响 + 中概率）→ 选 Event-Driven
风险4：第三方依赖（低影响 + 中概率）→ 接受实战 2：架构决策记录（ADR）
格式：
# 标题
## 状态
## 背景（风险）
## 决策（架构风格）
## 后果（收益 + 代价）
## 备选实战 3：避免过度工程
信号：
- 用了 3+ 种架构风格
- 每个都用一点
- 团队不理解为什么用
→ 可能过度工程
→ 退回到"风险驱动"重新评估六、性能指标
| 指标 | 衡量 |
|---|---|
| 架构风格数 | 项目用了多少种风格（少=好） |
| 每个风格的风险对应 | 是否每个风格都有对应的风险 |
| 架构变更影响 | 改架构需要改多少代码 |
| 团队理解度 | 团队是否能解释为什么用每种风格 |
七、边界判断
何时用风险驱动：
- 任何架构决策
- 任何技术选型
何时不用风险驱动：
- 紧急情况（先用再说）
- 团队共识已经形成
- 行业标准（如 Web 用 HTTP）
何时重新评估：
- 业务变化
- 团队变化
- 技术变化
- 性能问题
八、与其他 L 层方法论的关系
| 方法论 | 关系 |
|---|---|
| clean-hexagonal | 风险驱动选 Hexagonal |
| cqrs-es | 风险驱动选 CQRS |
| microservice-or-monolith | 风险驱动选架构 |
| compound-control（结构） | 风险驱动选复合控制 |
| architecture-evolution（主题） | 风险驱动贯穿演进 |
九、钱学森原话
Ch 4 §4.8（三难）： "片面的追求某一个高指标会使其他的性能受到影响"——架构风格有代价。
Ch 9 §9.4（最优存在性）： "在进行控制设计时，首先重要的是搞清楚最优控制是否存在"——架构需要 justify。
十、总结
风险驱动架构 = 每个架构风格缓解一个风险：
| 步骤 | 行动 |
|---|---|
| 1 | 识别风险 |
| 2 | 评估影响 × 概率 |
| 3 | 为高风险选架构 |
| 4 | 接受低风险 |
| 5 | 记录 ADR |
| 6 | 定期回顾 |
核心原则：
- 每个架构风格 = 一个风险缓解
- 没用 = 不需要
- 用过 = 记录在 ADR
- 定期回顾（业务变化）
一句话总结：架构不是工具箱，是风险缓解工具集。
相关链接
L 层方法论
控制结构
业务主题
- 架构演进（风险驱动的演进路径）
源典
- IDDD Ch 4（Architecture 风险驱动）
- 工程控制论 Ch 4 §4.8（三难困境 = 架构不能全要）
- 工程控制论 Ch 9 §9.4（最优控制存在性 = 架构需 justify）