Views & Decisions（架构视图与决策记录）

解决什么问题：让架构"看得见、可讨论、可回溯"—— 没有视图 = 架构只在某个人脑子里，换人就丢。没有决策记录 = 3 个月后没人记得"当初为什么这样设计"，重新踩坑。

它是什么

架构视图（Views）——同一架构从不同视角看到的切片。一套图覆盖 4+1 视图：

逻辑视图：模块、BC、领域对象（给开发看）
开发视图：包结构、模块依赖、构建顺序（给构建系统看）
运行视图：进程、部署、网络拓扑（给运维看）
数据视图：数据模型、存储、迁移（给 DBA 看）
场景视图（+1）：用 use case 把上面 4 视图串起来

架构决策记录（ADR, Architecture Decision Records）——每个关键架构决策的"为什么"。格式：

# ADR-001: 选择 Kafka 作为事件总线
## 状态：已接受 / 已废弃
## 背景：需要可靠的事件传递
## 决策：用 Kafka
## 后果：运维成本↑，但社区成熟 / ...
## 替代方案：考虑过 RabbitMQ，原因是……但放弃，因为……

SE@G Ch 19："Each view addresses a specific set of concerns... software architecture is not a single structure."

V2 视角（V2.7 B1 段 2 "搞清楚是什么"）：视图是"认识架构"的工具——光说"我们用了微服务"等于没说，必须配视图让人能"看到"。

关键属性

属性	视图	决策记录
受众	不同角色（开发 / 运维 / DBA / PM）	全体工程师
形式	图 + 关键文字	Markdown 文件
数量	4+1 视图，每视图 1-3 张图	每个决策 1 个 ADR
位置	仓库 `/docs/architecture/`	仓库 `/docs/adr/`
更新频率	大变化才更新	每次大决策都新增
反模式	一张总图试图讲清一切	决策只在群里口头说
判错标志	看不到完整架构	半年后没人能说清当初为啥

怎么用

场景 1：搭建 4+1 视图骨架（项目启动）

/docs/architecture/
├── 01-logical-view.md       ← 模块 / BC / 领域关系
├── 02-development-view.md   ← 包结构 / 模块依赖
├── 03-process-view.md       ← 进程 / 部署 / 网络
├── 04-data-view.md          ← 数据模型 / 存储
├── 05-scenarios.md          ← +1：关键 use case 路径
└── /diagrams/               ← 图源文件（drawio / mermaid）

最小视图集（小团队起步）：

1 张 BC 关系图（Context Map）
1 张模块依赖图（哪些模块依赖哪些）
1 张部署拓扑图（服务 / DB / 消息队列）

场景 2：写 ADR（Architecture Decision Record）

markdown

# ADR-007: 订单聚合不分库存（一致性边界选择）

## 状态：已接受（2026-05-12）

## 背景
订单系统需要在下单时保证库存预占。
候选方案：
A. 把库存塞进 Order 聚合（同聚合强一致）
B. Order 聚合 + 库存聚合（跨聚合最终一致 + 事件）

## 决策
选 B。Order 聚合只引用 ProductId，库存独立聚合。

## 原因
- 选 A 的代价：并发差（一个用户下单锁整个订单）、
  性能差（每次下单都查库存表）、库存团队无法独立演进
- 选 B 的代价：偶发超卖（靠"预占 + 补偿"兜底），
  但并发性能高 10 倍以上

## 后果
- 引入 Outbox 模式保证事件可靠发送
- 引入"库存预占" 表（带 TTL）
- 接受"超卖 ≤ 0.1%" 的业务承诺

## 替代方案为何放弃
- A（同聚合）：上面说过了，性能不可接受
- C（库存独立服务）：目前规模不需要，过度拆分

## 触发重审的条件
- 实际超卖率 > 0.5%
- 团队规模 > 50 人（需要库存独立团队）

场景 3：视图在评审 / 入职时的用法

架构评审：评审前 1 周发 4 视图 + ADR list，让评审人带着问题来——

"逻辑视图里 BC A 和 BC B 之间的依赖合理吗？"
"ADR-005 的决定今天还成立吗？"

新人入职：

Day 1：读 4 视图（半天）→ 看到系统全貌
Week 1：读所有 ADR（1 天）→ 知道每个决策的来龙去脉
Month 1：开始写 ADR（参与架构讨论）

场景 4：视图与决策的"保鲜"机制

V2 B7 段 5 "演化纪律"：

视图：每次大变更（架构级）必须更新对应视图 + 标日期
ADR：只新增，不修改旧 ADR——如果决策反转，写 ADR-N 来 supersede ADR-M
季度回顾：扫一遍 ADR，把"触发重审条件"已触发的挑出来重审

docs/adr/
├── 0001-record-architecture-decisions.md   ← 模板 ADR
├── 0002-choose-monolith.md
├── 0007-order-aggregate-no-stock.md       ← 已接受
├── 0008-stock-eventual-consistency.md     ← 已接受
└── 0015-stock-supersede-0007.md          ← 反转 0007，新 ADR

常见误区

"一张总图 = 架构"——错。不同角色需要不同视图。一张总图谁也看不清
"架构只在文档里"——错。架构必须实现可见（包结构、模块名、目录组织要和视图一致）
"ADR = 设计文档"——错。ADR 只记决策（为什么选这个、不选别的），不记设计细节
"决策一旦记录就不能改"——错。决策会被反转——反转时写新 ADR supersede 旧的，保留历史
"视图画完就完了"——错。视图和代码必须持续同步，否则视图变成"谎言"

关键洞察

视图让人"看到"架构，决策记录让人"看懂"架构——两者缺一不可。
没有视图 = 黑盒架构，靠口口相传。没有 ADR = 架构决策变成"传话游戏"，3 个月后失真。
V2 B1 段 2"搞清楚是什么"的工程纪律：任何架构讨论前，先确认"我们在哪个视图讨论"——避免在"逻辑视图" 讨论"运行视图"的问题，造成鸡同鸭讲。

Views & Decisions（架构视图与决策记录） ​

它是什么 ​

关键属性 ​

怎么用 ​

场景 1：搭建 4+1 视图骨架（项目启动） ​

场景 2：写 ADR（Architecture Decision Record） ​

场景 3：视图在评审 / 入职时的用法 ​

场景 4：视图与决策的"保鲜"机制 ​

常见误区 ​

关键洞察 ​

相关链接 ​