多层次 / 多视图软件架构
一篇讲清：是什么、为什么、怎么画、怎么用很多人把多层次架构 和多视图架构 混为一谈，其实它们是软件架构的两个核心维度：
一个管上下分层 ，一个管多角度拆解。
合在一起，才是一套完整、严谨、可落地的架构描述方法。
一、先一句话分清两者
- 多层次架构（Layered Architecture）
从底层到上层 的垂直划分，解决：依赖关系、职责隔离、复杂度控制。
- 多视图架构（Multi-View Architecture）
从不同视角 看同一个系统，解决：不同人关心不同事、沟通统一、架构完整。
一个是结构分层 ，一个是视角拆分。
二、多层次架构（垂直分层）
1. 核心思想
把系统按**"抽象级别"或"依赖方向"**从上到下分成多层：
-
上层依赖下层
-
下层不依赖上层
-
层与层之间通过接口交互
-
禁止跨层乱调用
目标：高内聚、低耦合、易维护、易替换。
2. 经典多层模型
（1）通用 4 层架构（最常用）
- 表现层 / UI 层
界面、交互、前端、可视化
- 应用层 / 业务逻辑层
流程、规则、服务编排
- 领域层 / 核心逻辑层
业务实体、算法、核心规则
- 基础设施层 / 数据&驱动层
数据库、文件、网络、硬件驱动、中间件
（2）工业软件多层架构
-
设备驱动层
-
数据采集层
-
运动控制/算法层
-
任务调度层
-
应用接口层
-
UI 交互层
（3）云原生多层
-
接入网关
-
微服务层
-
数据访问层
-
存储与中间件层
3. 优点
-
结构清晰，新人易理解
-
某一层替换不影响其他层（比如换数据库、换UI）
-
便于分工开发
-
便于测试、定位问题
4. 缺点
-
层太多会增加调用链路
-
设计不好容易出现"跨层调用"，导致退化
三、多视图架构（多角度拆解）
1. 核心思想
同一个系统，不同角色看到的内容不一样。
架构师不能只画一张图，必须从多个视角完整描述系统。
最经典、最权威的就是：
"4+1 视图模型" ------ Philippe Kruchten 提出，软件行业标准。
2. 4+1 视图详细解释
1）逻辑视图（Logical View）
-
面向：架构师、开发人员
-
关注：模块划分、类、组件、职责、关系
-
产出：模块图、类图、组件图
-
一句话：系统由哪些部分组成？
2）开发视图（Development View）
-
面向：程序员、开发组长
-
关注：代码结构、工程组织、模块依赖、库、框架
-
产出：项目结构图、依赖图
-
一句话：代码怎么组织、怎么编译？
3）进程视图（Process View）
-
面向：系统工程师、运维
-
关注：并发、线程、进程、通信、同步、性能
-
产出：进程线程图、时序图
-
一句话：系统跑起来怎么并发、怎么交互？
4）物理视图（Physical View）
-
面向：运维、部署工程师
-
关注：机器、节点、网络、部署、硬件
-
产出：部署图、网络拓扑
-
一句话：软件最终部署在哪些设备上？
+1 场景视图（Scenarios View）
-
面向：所有人
-
关注：核心业务流程、用例、关键路径
-
产出：用例图、时序图
-
一句话：系统真正跑起来是什么样？
3. 为什么要多视图？
-
产品经理看场景视图
-
开发看逻辑视图 + 开发视图
-
运维看物理视图
-
性能优化看进程视图
一套视图，统一所有人的语言。
四、多层次 + 多视图 = 完整架构
实际工作中，它们是组合使用的：
-
先用多层次把系统垂直切分，保证结构干净；
-
再用多视图把每层从不同角度描述清楚；
-
最终形成一套完整架构文档。
可以理解为：
-
多层次 = 建筑的楼层结构
-
多视图 = 平面图、立面图、水电图、暖通图
五、极简总结
-
多层次架构 ：从上到下分层，管住依赖与职责。
-
多视图架构 ：从多角度拆解，管住沟通与完整度。
真正成熟的软件架构，
一定是多层结构 + 多视图描述共同支撑。
