夜雨聆风做软件架构，最怕的就是一张图讲不清、一群人听不懂。
产品关心功能、开发关心代码、运维关心部署、老板关心性能……众口难调，怎么办？
今天给大家讲一个软件架构界的经典神作——
Kruchten「4+1」视图模型，几乎所有架构师都绕不开它。
一、什么是 4+1 视图？一句话讲明白
1995 年，Philippe Kruchten 提出了一套从 5 个角度看系统的方法，后来被 RUP 统一过程采纳，成为行业标准。
4 个核心视图：分别对应功能、开发、运行、部署
+1 个场景视图：把前面 4 个视图串起来，验证架构对不对
简单说：
4 个视图搭骨架，1 个场景验全身。
二、4 个核心视图，分别管什么？
1. 逻辑视图：系统到底能做什么？
给谁看：用户、产品、业务分析师
关心什么：功能、业务逻辑、数据结构
画什么：类图、对象图、用例图
一句话：系统对外提供什么能力，不关心代码怎么写
逻辑视图回答：
系统要做什么。
2. 开发视图：程序员怎么写代码？
给谁看：开发、项目经理
关心什么：代码结构、模块划分、依赖关系、复用
画什么：组件图、包图
一句话：代码怎么组织、工程怎么管理
开发视图回答：
系统怎么开发、怎么维护。
3. 进程视图：系统跑起来卡不卡？
给谁看：集成、运维、性能测试
关心什么：并发、线程、同步、性能、吞吐量、容错
画什么：活动图、时序图、进程图
一句话：系统运行时的动态表现
进程视图回答：
系统运行效率高不高、稳不稳。
4. 物理视图：软件最终部署在哪？
给谁看：运维、系统工程师、网络工程师
关心什么：硬件、服务器、网络、部署位置
画什么：UML 部署图
一句话：软件映射到硬件上的样子
物理视图回答：
系统部署在哪台机器、怎么分布式运行。
三、+1：场景视图——架构的“粘合剂”
很多人疑惑：为什么是 4+1，不是直接 5 个视图？
因为这个“+1”很特殊：
它不单独描述某一块
它用关键业务场景、核心用例（如登录、下单、支付）
把逻辑、开发、进程、物理四个视图串在一起
验证架构是否通顺、是否满足真实业务
场景视图是：
架构设计的起点，也是最终验收的依据。
四、一张表看懂 5 个视图区别
视图 | 主要给谁看 | 关心什么 | 解决什么问题 |
|---|---|---|---|
逻辑视图 | 用户、业务 | 功能、业务逻辑 | 系统做什么 |
开发视图 | 程序员、开发 | 代码、模块、结构 | 怎么开发维护 |
进程视图 | 集成、运维 | 并发、性能、运行 | 系统怎么高效跑 |
物理视图 | 运维、网络 | 部署、硬件、拓扑 | 软件装在哪 |
场景视图 | 所有人 | 业务流程、架构验证 | 架构对不对、通不通 |
五、4+1 视图到底好在哪？
分而治之，不信息过载
不同角色只看自己的视图，沟通成本大幅降低。
全覆盖，不缺不漏
功能、代码、运行、部署一网打尽，架构不会跑偏。
场景驱动，不纸上谈兵
一切围绕真实业务，避免华而不实的架构。
通用极强
单体、分布式、微服务都能用，不挑语言不挑技术。
六、最后小结
逻辑视图 → 做什么（功能）
开发视图 → 怎么写（代码）
进程视图 → 跑咋样（性能）
物理视图 → 部署哪（硬件）
场景视图 → 串起来（验证）
**4 个视图立骨架，1 个场景定全局。
这就是 Kruchten 4+1 视图模型的精髓。**
