别再只画一张类图了：一个架构师眼中的 4+1 模型

做架构这些年，我见过太多人把“架构设计”理解成画一张大而全的类图，或者甩出一张部署图就交差。客户看不懂，开发觉得没用，运维说对不上实际环境。问题往往不在技术本身，而在于我们试图用一个视角讲清楚所有事情。

Philippe Kruchten 在 1995 年提出的 4+1 视图模型，解决的就是这个问题。它不是什么高深理论，而是一套很实用的“分视角说话”的方法。今天我想从自己的使用经验出发，把这个模型讲清楚。

为什么需要多个视图？

软件系统复杂起来之后，不同角色关心的点完全不一样。

产品经理和客户关心的是：系统能干什么？用户怎么用？
开发关心的是：代码怎么组织？模块之间怎么依赖？
做性能和并发的人关心的是：运行时有多少进程和线程？它们怎么通信？
运维和基础设施的人关心的是：软件最终跑在哪些机器上？网络怎么连？

如果只用一张图试图满足所有人，结果通常是谁都看不明白。4+1 模型的核心思路很简单：针对不同关注点，用不同的视图来描述同一个系统，最后再用场景把它们串起来验证。

所谓“4+1”，前面四个是核心视图，后面的“+1”是场景视图。

四个核心视图分别看什么

1. 逻辑视图（Logical View）

这是最接近“功能”的视图。

它回答的问题是：系统由哪些功能单元组成？它们之间有什么关系？

在面向对象的项目里，逻辑视图通常用类图、包图来表达。你看到的是关键的业务对象、它们的职责，以及协作关系。对客户和产品经理来说，这是最容易理解的一张图——它直接对应需求。

我自己做架构时，逻辑视图一般最先画。先把业务概念理清楚，再往下拆。很多团队容易在这里陷入细节，把所有类都画上去。其实没必要。逻辑视图应该保持在“架构级”，只保留那些对整体结构有影响的抽象。

2. 开发视图（Development View）

开发视图站在程序员的角度看系统。

它关注的是：代码在开发环境中如何组织？模块怎么划分？依赖关系是什么？

常见的表现形式是包图、组件图，或者直接是项目的目录结构和模块依赖关系。微服务拆分、Maven/Gradle 多模块结构、前后端分离的边界，都属于开发视图要说清楚的内容。

这个视图对团队协作特别重要。新成员进来，先看开发视图，能快速知道“代码放在哪里、改一个功能大概要动哪些模块”。如果开发视图混乱，往往意味着项目已经开始失控。

3. 进程视图（Process View）

进程视图看的是系统运行起来之后的样子。

它回答：有哪些进程、线程？它们如何通信？并发怎么处理？性能瓶颈可能在哪里？

时序图、活动图、进程通信图都是常用工具。消息队列、异步任务、线程池、锁策略，这些都应该在进程视图里体现。

我见过不少系统逻辑上看起来很清晰，一上线就出并发问题。原因往往是进程视图没认真做。逻辑视图描述的是“静态结构”，进程视图描述的是“动态行为”。两者缺一不可。

4. 物理视图（Physical View）

也叫部署视图。

它关注软件最终如何落到硬件和网络上：服务部署在哪些节点？数据库在哪里？负载均衡怎么配？跨机房怎么通信？

部署图是最直接的表达方式。现在的云原生环境里，物理视图还要考虑容器、K8s、服务网格这些内容。

运维和基础设施团队最关心这张图。很多线上故障，事后复盘发现是架构师和运维对物理部署的理解不一致。物理视图能有效减少这种错位。

+1：场景视图为什么重要？

前面四个视图是从不同角度“切开”系统来看。但它们之间是否一致？有没有遗漏？这就需要场景视图来验证。

场景视图通常选择几个关键用例或典型场景，用时序图或简单的文字描述，把逻辑、开发、进程、物理四个视图串起来走一遍。

比如一个“用户下单”的场景：

• 逻辑视图里涉及哪些业务对象？
• 开发视图里对应哪些模块？
• 进程视图里会触发哪些异步处理？
• 物理视图里请求会经过哪些节点？

走完几个核心场景，基本上能发现视图之间的矛盾和缺口。场景视图不是可有可无的补充，而是让整个 4+1 模型闭环的关键。

实际使用中的几点经验

第一，不是每个项目都要五张图都画得很完整。小系统可以合并简化，复杂系统再展开。关键是心里要有这几个视角，而不是为了画图而画图。

第二，视图之间要保持可追溯。逻辑视图里的一个功能模块，在开发视图里应该能找到对应的代码组织，在进程视图和物理视图里也能看到它的运行和部署方式。断了链，架构描述就失去了意义。

第三，架构文档是给人看的，不是写给自己留念的。每个视图都要明确“给谁看、解决什么问题”。客户看逻辑和场景，开发看开发和逻辑，运维看物理和进程。

第四，4+1 是方法，不是教条。现在很多团队会结合 C4 模型、架构决策记录（ADR）一起用。形式可以变，分视角思考的习惯值得保留。

写在最后

做了这些年架构，我越来越觉得：好的架构描述不是让人惊叹“好复杂”，而是让不同角色都能快速找到自己关心的信息，并且彼此能对上话。

4+1 模型的价值，正在于此。它提醒我们，软件系统从来不是单一视角能说清楚的。学会用多个视图说话，是架构师的基本功。

下次做架构设计时，不妨先问自己四个问题：

• 功能结构清楚了吗？（逻辑）
• 代码怎么组织？（开发）
• 运行时是什么样子？（进程）
• 最终部署在哪里？（物理）

然后再拿几个关键场景跑一遍。这套动作做扎实了，架构沟通会顺畅很多。

架构没有银弹，但有些基础方法经得起时间检验。4+1 就是其中之一。