软件架构概述
一、什么是架构？
架构是对系统中的实体以及实体之间的关系（结构、行为、属性）所进行的抽象描述，是一系列的决策。
架构风格是特定应用领域的惯用模式，定义了用于描述系统的术语表和一组指导构建系统的规则。
简单理解
架构 = 系统的骨架（有哪些部分、怎么连接、怎么约束） 架构风格 = 骨架的常见套路（比如分层、微服务、事件驱动等）
二、架构的作用
| 作用 | 说明 |
|---|---|
| 沟通与共识 | 解决项目干系人之间的沟通障碍，减少歧义，是交流的共同语言 |
| 可传递可复用 | 架构模型可以在不同项目间复用，通过研究架构可以预测软件质量 |
| 控制变更 | 使推理和控制更改更加简单，有助于循序渐进的原型设计，也是培训新人的基础 |
为什么需要架构图？
为了抽象地表示软件系统的整体轮廓和各组件之间的相互关系与约束边界，以及系统的物理部署和演进方向。要让干系人理解并遵循架构决策，就需要把架构信息传递出去——架构图就是一个很好的载体。
架构定义的本质
定义一个词汇表（系统由哪些东西组成）和一组约束（这些东西之间的规则和边界）。
三、4+1 视图模型
由 Philippe Kruchten 提出，用 5 个视图从不同角度描述软件架构，其中场景视图居中串联其余四个：
场景视图
（用例驱动）
/ | \
逻辑视图 流程视图 开发视图
\ | /
物理视图
场景视图（Scenarios）
- 描述什么：系统的参与者与功能用例之间的关系
- 反映什么：系统的最终需求和交互设计
- 常用图：用例图（Use Case Diagram）
- 服务于：所有干系人
核心地位
场景视图是其他四个视图的”胶水”——每个用例场景都会涉及逻辑组件、运行流程、开发模块和部署节点，因此用它来验证和串联其余视图。
逻辑视图（Logical View）
- 描述什么：系统软件功能拆解后的组件关系、组件约束和边界
- 反映什么：系统整体组成与系统如何构建
- 常用图：组件图（Component Diagram）、类图（Class Diagram）
- 服务于：架构师、开发人员
流程视图（Process View）
- 描述什么：系统软件组件之间的通信时序、数据的输入输出
- 反映什么：系统的功能流程与数据流程
- 常用图：时序图（Sequence Diagram）、流程图（Flowchart）
- 服务于：开发人员、集成人员
开发视图（Development View）
- 描述什么：系统的模块划分和组成，细化到内部包的组成设计
- 反映什么：系统开发实施过程中的模块组织
- 常用图：包图（Package Diagram）、模块结构图
- 服务于：开发人员、项目管理者
物理视图（Physical View）
- 描述什么：系统软件到物理硬件的映射关系
- 反映什么：系统组件如何部署到计算机器节点上
- 常用图：部署图（Deployment Diagram）
- 服务于：运维人员、系统管理员
4+1 视图速查
| 视图 | 关注点 | 受众 | 典型图 |
|---|---|---|---|
| 场景视图 | 需求和交互 | 所有人 | 用例图 |
| 逻辑视图 | 功能组件与关系 | 架构师、开发 | 组件图、类图 |
| 流程视图 | 通信时序与数据流 | 开发、集成 | 时序图、流程图 |
| 开发视图 | 模块划分与包结构 | 开发、管理 | 包图 |
| 物理视图 | 软件到硬件的映射 | 运维、部署 | 部署图 |
用盖房子来类比
- 场景视图：业主的需求——几室几厅、要不要车库
- 逻辑视图：建筑师的平面图——哪里是客厅、哪里是卧室、怎么连通
- 流程视图：水电走线图——水从哪来、电怎么走、开关控制哪盏灯
- 开发视图：施工分包——哪个队负责地基、哪个队负责装修
- 物理视图：实际选址和建造——建在哪块地上、用什么材料