架构师画了100张图，老板说"挺好"——然后项目失败了

你有没有遇到过这种场景：

架构师花了一周，画了一套"完美"的架构图，给开发讲——开发说"看不懂，你这个类怎么没画出来"；给运维讲——运维说"你这个部署在哪？服务器呢"；给老板汇报——老板说"挺好挺好"；然后项目失败了，没人知道问题出在哪。

这不是哪个人的问题。这是一种图，根本装不下一个系统。

---

Kruchten何许人？他解决了什么问题

1995年，Philippe Kruchten（ Rational Software的首席架构师）提出了一个看似简单、实则革命性的观点：软件架构需要从5个不同视角来描述，而不是一张图打天下。

这就是"4+1"视图模型。4个基础视图，加上1个场景视图——场景视图是驱动其他四个视图的那个"+1"。

为什么这很重要？因为系统架构的"涉众"天然是多元的：产品经理关心功能，开发关心代码组织，运维关心部署，网络工程师关心拓扑，老板只关心"能不能按时上线"。

用一个视角去满足所有人，结果是所有人都觉得差一口气。

---

5个视图，各管一摊

1. 逻辑视图——给"要什么"的人看

关注点：功能需求

这个系统要做什么？有哪些模块？模块之间的关系是什么？

用到的UML图：类图、对象图。描述手段是Booch方法和OMT方法。

对应人群：最终用户、需求分析师、产品经理。

说白了，逻辑视图回答的是"这个系统解决什么问题"。

---

2. 进程视图——给"怎么跑"的人看

关注点：并发、同步、性能

系统运行时，有哪些进程/线程？它们怎么通信？同步机制是什么？

用到的UML图：序列图、活动图、状态图。

对应人群：系统集成师、开发人员。

进程视图回答的是"系统运行时是怎么运转的"。如果你关心吞吐量、响应时间、线程安全，这个视图是主战场。

---

3. 开发视图——给"怎么写"的人看

关注点：软件开发组织

代码怎么组织？分了多少层？模块之间的依赖关系是什么？谁依赖谁？

用到的UML图：包图、组件图。

对应人群：程序员、软件项目经理。

开发视图回答的是"代码怎么组织方便开发和维护"。这是开发人员每天打交道最多的视角。

---

4. 部署视图——给"怎么部署"的人看

关注点：物理部署、拓扑结构

系统部署在哪些服务器上？节点之间怎么连接？网络配置是什么？

用到的UML图：部署图。

对应人群：系统集成师、网络工程师、运维团队。

部署视图回答的是"系统在物理上是怎么跑起来的"。如果你关心灾备、扩容、网络拓扑，看这个。

---

5. 场景视图——那个"+1"，是老大

关注点：用例场景

场景视图是整个模型的核心驱动力。它描述的是：用户和各种系统行为之间的交互。

用到的UML图：用例图。

对应人群：所有涉众。

场景视图的作用是串联其他四个视图——它像一条线，把逻辑、进程、开发、部署串在一起，让所有人不只是看到各自的部分，而是看到整个系统是怎么联动运转的。

---

为什么你画的图总被吐槽"看不懂"

回到开头的场景。架构师画了一套图，被开发说看不懂。

问题往往在于：架构师画的是自己最熟悉的视图，但其他人不熟悉。

开发看部署视图——"这节点我怎么对应到代码？"运维看逻辑视图——"你这类图跟我部署有什么关系？"老板看进程视图——满屏的线程同步，"你直接告诉我能不能抗住双十一。"

每个视图都有自己对应的"语言"，不同的人只听得懂自己的母语。

---

怎么用？电商系统举个例子

假设你在设计一个秒杀系统。

逻辑视图：用户下单、库存扣减、支付回调、订单生成——这是功能层面的抽象。

进程视图：前端限流 → 消息队列 → 秒杀服务多线程处理 → 库存服务 → 支付回调——这是运行时并发模型的刻画。

开发视图：分成了多少个微服务？每个服务的Maven/Gradle模块怎么组织？公共依赖谁管？

部署视图：前端Nginx、秒杀服务集群、库存Redis集群、数据库主从——节点之间的网络怎么走。

场景视图：用户从点击"立即抢购"到下单成功的完整流程，串起上面所有视图。

当产品经理问"能不能抢到"时，你看逻辑视图；当开发问"超卖怎么处理"时，你看进程视图；当运维问"要不要加机器"时，你看部署视图。

用对的语言，对的人，才能做对的决策。

---

所以呢？

"4+1"视图不是一个考试知识点，它是架构沟通的方法论。

真正理解了这一点，你会发现：

架构评审不是"我讲你听"，而是针对不同的人，切换不同的视图语言。开发问你架构，先拿开发视图；运维问你，先拿部署视图；老板问你，先拿场景视图——让他看到完整的用户旅程，比给他看一百个类图有效得多。

下次画架构图之前，先问自己一句：这张图是给谁看的？他关心什么？

想清楚这个问题，你已经比80%的架构师做得更好了。