1.前言

你是否对大厂展示的五花八门，花花绿绿的架构设计图所深深吸引，当我们想用几张图来介绍下业务系统，是不是对着画布不知从何下手？作为技术扛把子的筒子们是不是需要一张图来描述系统，让系统各个参与方都能看的明白？

如果有这样的困惑，本文将介绍一些画图的方法论，让技术图纸更加清晰。

2. 架构的定义

在TOGAF企业架构理论中，架构是从公司战略层面，自顶向下的细化的一部分，从战略=> 业务架构=>应用/数据/技术架构，当然老板层关注的是战略与业务架构，我们搬砖的需要聚焦到应用/数据/技术架构这一层。

3.架构图的分类

系统架构图是为了抽象的表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。好的架构图可以让干系人理解、遵循架构决策，就需要把架构信息传递出去。那么，画架构图是为了：解决沟通障碍/达成共识/减少歧义。比较流行的是4+1视图和C4视图。

3.1 4+1视图

3.1.1 场景视图

用于描述系统的参与者与功能用例间的关系,反映系统的最终需求和交互设计，通常由用例图表示;

3.1.2 逻辑视图

用于描述系统软件功能拆解后的组件关系，组件约束和边界，反映系统整体组成与系统如何构建的过程，通常由UML的组件图和类图来表示。想成为架构师？这份《史上最全架构师知识图谱》分享给你。

3.1.3 物理视图

用于描述系统软件到物理硬件的映射关系,反映出系统的组件是如何部署到一组可计算机器节点上，用于指导软件系统的部署实施过程。

3.1.4 处理流程视图

用于描述系统软件组件之间的通信时序,数据的输入输出,反映系统的功能流程与数据流程,通常由时序图和流程图表示。

3.1.5 开发视图

开发视图用于描述系统的模块划分和组成,以及细化到内部包的组成设计,服务于开发人员,反映系统开发实施过程。想成为架构师？这份《史上最全架构师知识图谱》分享给你。

5 种架构视图从不同角度表示一个软件系统的不同特征，组合到一起作为架构蓝图描述系统架构。

3.2 C4视图

下面的案例来自C4官网，然后加上了一些笔者的理解。

C4 模型使用容器（应用程序、数据存储、微服务等）、组件和代码来描述一个软件系统的静态结构。这几种图比较容易画，也给出了画图要点，但最关键的是，我们认为，它明确指出了每种图可能的受众以及意义。

3.2.1 语境图(System Context Diagram)

用于描述要我们要构建的系统是什么，用户是谁，需要如何融入已有的IT环境。这个图的受众可以是开发团队的内部人员、外部的技术或非技术人员。

3.2.2 容器图(Container Diagram)

容器图是把语境图里待建设的系统做了一个展开描述，主要受众是团队内部或外部的开发人员或运维人员，主要用来描述软件系统的整体形态，体现了高层次的技术决策与选型，系统中的职责是如何分布的，容器间是如何交互的。

3.2.3 组件图(Component Diagram)

组件图是把某个容器进行展开，描述其内部的模块，主要是给内部开发人员看的，怎么去做代码的组织和构建，描述了系统由哪些组件/服务组成，了组件之间的关系和依赖，为软件开发如何分解交付提供了框架。

4.怎么画好架构图

上面的分类是前人的经验总结，图也是从网上摘来的，那么这些图画的好不好呢？是不是我们要依葫芦画瓢去画这样一些图？先不去管这些图好不好，我们通过对这些图的分类以及作用，思考了一下，总结下来，我们认为，明确这两点之后，从受众角度来说，一个好的架构图是不需要解释的，它应该是自描述的，并且要具备一致性和足够的准确性，能够与代码相呼应。

4.1 视图的受众

在画出一个好的架构图之前， 首先应该要明确其受众，再想清楚要给他们传递什么信息 ，所以，不要为了画一个物理视图去画物理视图，为了画一个逻辑视图去画逻辑视图，而应该根据受众的不同，传递的信息的不同，用图准确地表达出来，最后的图可能就是在这样一些分类里。那么，画出的图好不好的一个直接标准就是：受众有没有准确接收到想传递的信息。