4+1 视图是什么
4+1 视图模型由 Kruchten 提出，用逻辑视图、进程视图、开发视图、物理视图四个视图分别面向不同关注点，再用场景视图串联并验证其余四个视图能否支撑关键用例。它的价值在于承认架构无法用一张图说清：业务关心功能划分，运维关心部署拓扑，开发关心代码组织，性能工程师关心并发与进程，各取所需又能互相对照。
5 个视图
| 视图 | 关注点 | 主要读者 |
|---|---|---|
| 逻辑视图 | 功能与领域模型、关键抽象 | 业务与设计人员 |
| 进程视图 | 并发、进程、线程与通信 | 性能与中间件工程师 |
| 开发视图 | 代码组织、模块与依赖 | 开发与构建工程师 |
| 物理视图 | 部署与网络拓扑、节点分布 | 运维与基础设施团队 |
| 场景视图 | 关键用例串联验证 | 全体评审者 |
基本信息
| 提出者 | Philippe Kruchten，用于描述软件密集型系统的架构 |
|---|---|
| 产物形式 | 不限定记法，可分别用类图、组件图、部署图与顺序图承载 |
| 与 C4 的关系 | C4 更强调层级递进与单一读者，4+1 更强调多视角并行 |
| 常见裁剪 | 小型系统可只保留逻辑、开发与物理三个视图 |
| 维护成本 | 视图数量与维护成本成正比，按干系人需求裁剪 |
典型使用场景
- 架构评审：为不同角色准备对应视图，避免一份文档谁都看不懂
- 跨团队沟通：逻辑视图对齐功能边界，物理视图对齐部署责任
- 性能评估：用进程视图分析并发模型与线程资源占用
- 运维交接：以物理视图说明节点、网络与中间件分布
- 方案验证：用场景视图走通关键用例，检查四个视图是否自洽
- 遗留系统梳理：分别补齐视图，发现文档与实际实现不一致之处
场景视图不是附属品：用关键用例把四个视图串起来走一遍，能发现大量单看某个视图时看不到的矛盾，例如逻辑上独立而部署上必须同机。
五个视图各自维护且互不引用，会出现逻辑视图与物理视图矛盾而长期无人发现的局面。