如何画出优秀的系统架构图

架构图的分类

系统架构

业务架构

应用架构

部署架构

物理架构

逻辑架构

4+1 架构视图

95 年提出的国际标准规范, 但是国内企业很少使用 4+1 视图, 其原因有:

1. 现在架构复杂度增加, 分布式系统大行其道.

2. 绑定 UML 图, 用 UML 图画架构图表达能力有问题, 丑

3. 理解困难,各视图容易混淆.

逻辑视图: 系统提供给用户的功能, UML 的 class 和 state diagrams(状态图)

处理视图: 系统处理过程, 对应 UML 的 sequence 和 activity diagrams

开发视图: 程序员角度看系统的逻辑组成, 对应 UML 的 pckage diagrams

物理视图: 系统工程师角度看用户的屋里组成, 对应 UML 的 deployment diagrams

场景视图: 用户角度看系统的实现需求, 对应 UML 的 use case diagrams

大厂常用架构图

业务架构

定义: 描述对用户提供了什么业务功能. 类似于 4+1 中的场景视图

使用场景:

1. 产品人员规划业务

2. 给领导汇报业务

3. 架构培训

技巧:

1. 通过不同颜色标识业务状态

2. 业务管理分组

客户端架构、前端架构

定义: 客户端和前端的领域逻辑架构, 类似于 4+1 的逻辑视图

使用场景:

1. 整体架构设计

2. 架构培训

技巧:

1.通过不同颜色标识不同角色

2.通过连接线标识关系

系统架构

定义: 后端逻辑架构, 后端架构, 技术架构

使用场景:

1. 整体架构设计

2. 架构培训

技巧:

1.通过不同颜色标识不同角色

2.通过连接线标识关系

如果系统架构复杂, 通过功能示意图+交互示意图来表达

应用架构

定义:描述后端系统有哪些应用组成

使用场景:

1. 项目开发、测试

2. 部署发布

3. 子与架构设计

画图技巧:

1.通过不同颜色标识不同角色

2.通过连接线标识关系

QA: 应用架构和系统架构有什么关系?

应用架构有时候也是系统架构, 一般的技术中间件如 MongoDB 的系统架构也是其应用架构. 如果业务系统复杂, 需要分别进行系统架构和应用架构描述, 那两种架构图描述是不一样的.

部署架构

定义: 描述后端系统是如何部署的, 对应 4+1 视图的物理视图

使用场景:

1. 总体架构设计

2. 运维规划和优化

画图技巧:

用图标代表区块

系统序列图(System Sequence Diagram)

QA: 为什么需要系统架构图?

静态架构图(组成角色 Role + 角色关系 Relation)无法描述运作规则 Rule, 所以需要动态架构图来描述