4+1，顾名思义，就是为不同的利益相关者（stakeholders）准备 4 种不同的视角和 1 种场景来阐述架构的设计意图，以便减少认知和交流的成本。
前言
这不是一个新的理论，出现也已经不少年了，设计初衷可能是为了让软件从业人员以一个更全面的角度去观察业务需求，不要一接收到需求就把视线投入到某个模块或者领域的细节。一个系统往往涉及到多个协作部门、网络协议、中间件等，不能过度抽象与简化，须知简化的前提就是引入一定的假设，而引入假设就是场景特殊性的增强，要素缺失，容易闭门造车，所以越是复杂的问题，就越是需要分而治之的思维方式来处理。
最早由Philippe Kruchten 提出，在1995年的《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文。
分类
- 4：逻辑视图、运行视图、物理视图、开发视图
- 1：场景视图
| 视图 | 利益方 | 常用图类 | 说明 |
|---|---|---|---|
| 场景视图 | 使用方 | 用例图 | 也称用例视图，是其他视图的概括 |
| 逻辑视图 | 需求方 | 分层架构图 | 问题领域的抽象，包含系统模块，中间件等 |
| 运行视图 | 程序员 | 时序图、流程图 | 多维抽象，关注并发和同步的特征 |
| 物理视图 | 运维 | 部署图 | 描述系统在硬件上的映射 |
| 开发视图 | 程序员 | 类图、组件图 | 描述系统在开发环节的静态组织结构 |
几点思考
- 这几个视图共同构成一个架构图，不同视图之间有着相互支撑的关系。
- 让软件从业人员从多个维度来考虑问题，比如逻辑层，物理层，子系统，模块，接口，进程，线程，消息，协议，设计边界等。
- 设计的过程，也是发现或者创造约束的过程，一个架构的失败，往往是在不知不觉中，引入了越来越多的约束，不能凸显系统的根本作用。
- 大众化、普适化的设计方案，一般情况下可以直接选用，但也需要根据实际业务进行适当调整，避免教条主义的惰性思维带来的风险，比如一股脑的微服务、容器化等。
- 在设计的最初环节，不需要引入过多的细节，否则业务逻辑不能清晰的体现出来，也无形增加了认知和交流成本。
几个要点
- 项目背景介绍，可以简单描述，甚至一行就行；但是需要附带项目参与人的信息和时间节点，比如
需求背景：因为xxxx，提高xxxxxxxxx
产品：张三
UI：赵文
测试：李四
前端：阿达
服务端：五七
联调部门：xx
联调对接人：英达
联调时间：2021.01.20
提测时间：2021.02.01
上线时间：2021.02.10
- 用例图需要体现出给用户带来的核心价值功能点；
- 时序图需要体现系统边界，每个功能需要经过哪几个系统的合作；
- 功能架构，需要体现系统所能支持的功能变化；
- 运行架构需要体现服务的调用和依赖；
- 实体架构，需要体现实体边界，实体状态的变化；
