我懂了，原来这就是4+1架构模型！

大家好，我是飘渺。今天继续带来架构师之路系列文章。

之前我们讲架构描述的时候提到过，一个有效的架构描述需要做到以人为本，不同的利益相关方展示不同的视点及视图。

那究竟需要从哪些视点入手，应该展示哪些视图？这是个问题。

于是，1995年，Philippe Kruchten 在《IEEE Software》上发表了题为 The 4+1 View Model of Architecture 的论文，引起了业界的极大关注，在这个论文中，首次提出了使用 4+1视图 来解决这个问题。

4+1 视图

“4+1视图” 从5个不同的侧面来描述架构，其中包括4个主视图和一个冗余的场景视图。4个主视图分别如下：

• 逻辑视图（Logical View）：主要是整个系统的抽象结构表述，关注系统提供最终用户的功能。
• 进程视图（Process view）：处理视图关注系统动态运行时，主要是进程以及相关的并发、同步、通信等问题。
• 物理视图（Physical view ）：定义软件到硬件的映射，反映架构的分布式特性。
• 开发视图(Development View)：定义在开发环境中软件的静态组织结构。

在进行架构设计时，架构的各个关注点够归结于以上4个视图，同时使用一个场景视图对它们进行解释和说明，就形成了第5个视图，也就是4+1架构模型中的1。

4+1模型

在设计架构时，会基于每个视图对系统进行独立分解，每种分解都是基于这个视图的关注点而进行的。基于每个视图的分解都会使用相同的方法和步骤，把系统分解成组件并维持组件间交互的关系。但是每个视图构成的组件类型各不相同，这些组件的类型源自视图分解的需求。

01 逻辑视图

用于描述系统的功能需求，即系统给用户提供哪些服务；以及描述系统软件功能拆解后的组件关系、组件约束和边界，反映系统整体组成与系统如何构建的过程。

下面springcloud微服务的逻辑视图示例（仅部分），就描述了springcloud中各个功能组件。从这个图中，基本可以对springcloud有一个大颗粒度的了解。

springcloud微服务的逻辑视图

02 物理视图

开发出的软件系统，最终是要运行在物理或软件环境上。物理环境可能是服务器、PC机、移动终端等物理设备；软件环境可以是虚拟机、容器、进程或线程。部署视图就是对这个部署信息进行描述。在UML中通常由部署图表示。

物理视图

03 进程视图

处理视图，又称过程视图、运行视图。用于描述系统软件组件之间的通信时序，数据的输入输出。在UML中通常由时序图和流程图表示，如下图所示：

进程视图

04 开发视图

开发视图关注的是架构如何指导开发流程，在这个视图中，软件系统会被分解成小的子程序或软件包，并为每个子程序或软件包定义接口。系统设计人员会根据这些分解的子程序和软件包分配工作内容。

DDD分层视图

05 场景视图

场景视图是4+1架构模型中最重要的视图，其他4个视图都是以场景视图为核心的。它用于描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计。在UML中通常由用例图表示：

场景视图

小结

上面我们详细介绍了4+1架构模型，但是在公司实际架构活动中往往都是会自定义一套符合公司架构标准的架构设计模板，然后根据特定项目进行裁剪或补充，那我们为什么不直接使用上面提到的4+1架构模型进行架构设计呢？

个人觉得主要有三个方面的原因：

1. 系统复杂度增加：1995年提出4+1架构模型时系统大部分还是单体系统，现在基本是分布式系统的天下。4+1模型中的核心视图场景视图无法描述清楚整体业务。
2. 绑定UML图：4+1视图大部分绑定的是UML元素，颜值即正义，已经不符合今天的审美要求了。
3. 理解困难：4+1视图的逻辑视图、开发视图、处理视图比较容易混淆。