前言

作为架构师，如果你需要对复杂的业务进行应用落地，在前期设计过程，或者后期给领导、新同事、业务同学做汇报或者培训时，难免需要一些直观的图来表达你的信息，所谓一图胜过千言万语。

什么是架构

首先，架构图是一个软件开发工程中用到的一些列图的总称，针对不同的场景，不同的受众，需要有不同视角的架构图进行展示。

从字面意思上理解，架构图=架构 + 图，它是一种当前软件架构的一种表达方式。

我们都知道现实世界到软件世界的映射，是一个不断抽象的过程，这其中的方法就是不断地进行建立模型，所以架构的过程其实就是建模的过程，而架构图就是表达你建模过程的一种方式。

架构的理论

在架构时，有一些业界成熟的架构方法论和范式，能够便于我们进行学习和套用

4+1架构范式

4+1视图的核心理念是从不同的角度去剖析系统，看看系统的结构是什么样的，具体每个视图的含义是：

1. 逻辑视图：从终端用户角度看系统提供给用户的功能，对应 UML的 class 和 state diagrams。
1. 处理视图：从动态的角度看系统的处理过程，对应 UML 的 sequence 和 activity diagrams。
1. 开发视图：从程序员角度看系统的逻辑组成，对应 UML 的 package diagrams。

我们可以看到，4+1视图本身很全面也很规范，但是为什么在实际工作中，真正按照这个标准来画架构图的公司和团队并不多。其原因是这套标准是针对之前的单体应用提出来的架构方法，如今大多系统都是分布式系统，无法每个微服务都画出对应的开发视图

4R架构模型

一个完整的架构图分别需要有不同的表现形式。分别是顶层设计(Rank)、定义的系统角色(Role)、角色之间的关系(Relation)和运作规则(Rule)。如下图所示：

顶层设计Rank——业务架构/产品架构图

业务架构指的是使用一套方法论/逻辑对产品（项目）所涉及到的业务进行边界划分，核心点就是把业务边界通过不同颜色模块标识出来，并做分组，同时不需要去考虑具体技术点。这个是我们实际工作中画的最多的一种图，因为这种图一般是给领导汇报，产品人员规划业务，新员工培训用的，没有这个图很难讲清楚业务大概。例如下图所示：

在比如下面的产品架构图：

定义系统角色(Role)——应用架构/系统架构

应用架构更侧重于系统实现的一个总体架构，需要指出系统的层次、系统开发的原则、系统各个层次的应用服务，通过不同的颜色来标识角色，自顶向下分层设计。

如下图，系统应用分为数据层、服务层、通讯层、展示层，并西风写明每个层次的应用服务。

如果你觉得不需要花的那么细，那么也可以按下图所示进行展示：

展示角色之间的关系(Relation)——系统关系图

如果系统比较复杂，按照架构分层的角度来看，应用架构已经到了可执行程序这一层，例如支付中台这一类的系统，包含的应用可能有几百上千个，如果把整个支付中台所有的应用都在一张图里面展示出来，信息太多太密，可能会导致架构图都看不清。+这种情况下，应用架构一般都是按照子域来画应用架构图，可以参考支付中台的会员域的应用架构图