说起软件系统架构图，你可能会想到 4+1 视图，毕竟很多学习资料上都说它是架构图的标准。那么，到底什么是 4+1 视图呢？是不是只要按照 4+1 视图的标准去画，就没问题呢 ?

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

  一、架构复杂度增加二、绑定 UML 图：UML 图画架构图存在问题，主体问题是不美观，表达能力弱三、理解困难：逻辑视图、开发视图和处理视图非常容易混淆

  软件架构指软件系统的顶层（Rank）结构，它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规则（Rule）

  4R 是指 4 个关键词：Rank，Role，Relation 和 Rule。既然能够最终靠 4R 来定义软件系统的架构，那么按照 4R 架构定义的思路来画架构图也是很合情合理的，具体步骤如下

  第一步，明确 Rank：也就是说，不要事无巨细地把一个大系统的方方面面都在一张架构图中体现出来，而应该明确你要阐述的系统所属的级别（L0～L4），然后只描述这个级别的架构信息。第二步，画出 Role：从不同的角度来分解系统，看看系统包含哪些角色，角色对应架构图中的区块、图标和节点等。第三步，画出 Relation：有了角色后，画出角色之间的关系，对应架构图中角色之间的连接线，不同的连接线能代表不同的关系。第四步，最后画出 Rule：挑选核心场景，画出系统角色之间如何协作来完成某项具体的业务功能，对应系统序列图。

  我把描述 Role 和 Relation 的架构图称为静态架构图，描述 Rule 的系统序列图称为动态架构图

  从某一个角度去看，静态架构图的数量跟系统复杂度有关，一般是 1～2 张，如果最简单，用一张图就够了，如果很复杂，就要分别用两张图来展现；而动态架构图是一般是多张，因为核心场景数量不止一个，对应的系统序列图有多张

  【定义】描述系统对用户更好的提供了什么业务功能，类似于 4+1 视图的场景视图。

  【使用场景】产品人员规划业务：比如说我们大家常常在产品规划和汇报会议上看到产品人员会用业务架构图来展现业务全局状态。给高 P 汇报业务：对于 P7+ 以上级别的技术人员，在汇报的时候不能光讲技术，也要讲业务的发展状况，用业务架构图就非常容易的展现业务整体情况。给新员工素质培训业务。

  【画图技巧】通过不一样的颜色来标识业务状态：比如说哪些业务发展状态好，哪一些问题比较多，哪些较为稳定，哪些竞争比较激烈等。业务分组管理：将类似的业务放在一个分组里面展现，用虚线框或者相同背景将其标识出来。区块对齐：为了美观，能改变不同区块的长短大小进行对齐，让整体看起来更美观【参考案例】

  这张业务架构图有三点关键信息：1.“MTR”区块是浅红色的，“人传人”区块是绿色的，浅红色代表正在进行的，绿色代表明年规划的。2.分了 4 组：钱包业务、第三方业务、商家服务和用户管理。3.“转账”和“社交红包”等区块比较长，只是为了对齐后更美观，不代表业务本身的量级或者重要程度，如果要表示这样的信息，那就能用颜色来表示。

  注意，绝对不能画得五颜六色，一般一张图的颜色数量控制在 3 种以内是比较好的。所以在画图的时候你要想清楚，到底哪些信息是要放在业务架构图中重点展示的关键信息，哪些信息顺带讲一下就可以了。

  【定义】描述客户端和前端的领域逻辑架构，关注的是从逻辑的角度如何分解客户端或者前端应用

  【使用场景】整体架构设计：由客户端或者前端架构师完成本领域的架构设计架构培训。

  【画图技巧】1通过不一样的颜色来标识不一样的角色。2通过连接线来表示关系，如果有多种关系，例如有的是直接调用，有的是事件通知，那就能用不一样的形状的线分层或分组：将类似的角色分层或者分组管理。