看了一堂《如何画好架构图》的公开课，结合网上的资料与经验做一些思考总结。文中的例子和图片大多是从课程中摘录的。
1. 4R架构定义
4R架构定义其实是软件架构定义经过归纳提炼后的简称。
软件架构定义：软件架构是指软件系统的顶层（Rank）结构。它定义了系统由哪些角色（Role）组成，并描述了角色的关系（Relation）和运作规则（Rule）。关键词为 Rank、Role、Relation、Rule，所以简称为4R架构定义。
1.1 Rank
Rank指软件架构是分层的，是自上而下逐层细化的。大部分情况下，我们在讨论或画架构图的时候会针对某一层展开，最多涉及到3-4层，但是一定不要试图把每一层都搅合在一起进行讨论或画图。做架构的时候可以自上而下思考，在确定顶层之后逐层细化拆解，一般不要超过5层。下图是微信架构的例子。
1.2 Role
Role指在软件系统中的角色。角色就是每一层架构的组成部分，在每一层对应不同的内容，它可以是大的业务系统，也可以是小的能力、模块。
1.3 Relation
Relation指的是软件系统中各角色的关系。角色要放在一个层必然是存在某种关系的，或是相互合作为用户提供服务，或是数据上下游关系等。在讨论架构或画架构图的时候要能够清晰的定义这些关系。
1.4 Rule
Rule是指软件系统角色之间如何协作来完成系统功能。软件的目的是为用户提供服务，既然是提供服务则软件系统必然是运动的，这其中的运行逻辑就是规则。
2. 架构图的分类
在4R架构定义中可以把架构图分为两大类：静态架构图和动态架构图。在选定要讨论的层次（Rank） 之后，静态架构图描述系统架构中存在哪些角色（Role） 和角色之间的关系（Relation），动态架构图描述角色之间的协作规则（Rule）。两类架构图结合在一起看就能够了解到整个系统架构的全貌。
2.1 静态架构图
五种静态架构图中分别从业务角度、系统角度、物理角度描述了软件系统。
业务角度 是站在用户视角看系统，这个系统为我提供了什么样的服务。
系统视角 是从系统内部看系统，能看到系统内部有些什么能力，这些能力也许不能直接为用户提供服务，需要组合在一起才能完成服务。
物理角度 则是站在硬件层看系统，关注的是系统所需要的服务器、使用的中间件、机房位置、网络等信息。
2.1.1 业务架构图
业务架构图 描述的是系统对用户提供了什么业务功能，我理解为从业务角度来描述系统。一般用于给不了解系统的人介绍系统使用（业务概览），常在答辩、面试、培训等场景用到。
核心目的 是描述这个系统对用户提供了哪几个服务，这几个服务分别包含哪些功能（即告诉别人这个系统是干什么的）。
图片是从《如何画好架构图》里摘录的，这个例子里选取的层次是支付宝香港的业务。L0层是 钱包业务、商家服务、第三方业务和用户管理，这几个虚线框内部的是L1层。
2.1.2 前端架构图、系统架构图
客户端/前端架构图 和 系统架构图 从系统角度分别对前后端的架构进行了描述，常用于技术设计讨论、汇报、面试等场景。
核心目的 描述系统中现有的能力，能力点的逻辑划分及能力之间的关系。这里的能力可以是大的聚合能力，也可以是小的原子能力。
客户端/前端架构图：
系统架构图：
上面的系统架构图中核心描述的是支付中台内的系统架构，支付中台是L0，收银台、开放平台、配置中心、交易中心等是L1，内部最小的方框是L2。向看图的人展现了整个支付中台中的业务模块及各模块中的业务能力。因为这张系统架构图复杂度较高，所以没有标注关系，课程里也单独画了一张关系图如下。两张图（对应Role和Relation）结合在一起看就是整个系统架构的全貌。
2.1.3 应用架构图
应用架构图 也是从系统角度出发，主要针对后端的架构进行描述。常用于技术设计讨论、汇报、面试等场景。
应用架构图 从字面理解是描述整个系统拆分出的所有应用及应用之间的关系。而应用往往是按照能力归类划分，一类能力归属一个应用，如用户的增删改查都放到用户服务里。换言之 应用架构图 的核心目的是描述的是系统中的各类能力以及能力之间的关系。个人感觉 应用架构图 相比 系统架构图 层次更深，更偏向技术视角。
如果是微服务架构，则图里的每个Server就是一个微服务。如果是单体架构即一个系统只有一个应用，则这里面的Server可能是一个类或一个Package对外暴露的接口。在单体架构中应用架构图也可以是系统架构图。
2.1.4 部署架构图
部署架构图 偏物理视角，描述的是整个系统的应用部署、机房、中间件及网络等信息。主要应用于整体系统架构设计，运维规划和优化。
核心目的 是描述整个系统如何部署。
大型的互联网系统，需要考虑多城市部署，异地多活等方案，就需要做部署架构图。
2.2 动态架构图
动态架构图 主要描述系统中角色之间的互相协作规则（Rule），主要使用系统序列图来表现。
2.2.1 系统序列图
系统序列图 表示的是系统的一个核心场景的执行逻辑，每个核心场景都需要系统序列图。常用于需求设计、汇报等场景。
核心目的 是描述核心场景中系统的运行规则。只关注核心场景是因为核心场景重要且稳定（不易变化）。非核心场景数量多且易变化，一般只在做需求设计的时候画序列图。
3. 画图要点
个人理解画图没有统一的规范，能把系统说清楚就可以。有一些注意事项有些来自他人的文章，有些过往经验，在这里做一些总结。
简单专注
画图尽量简单专注，选好要讨论的层次，一般一张图最多涉及3-4层。大而全的图一般画不清楚，也看不清楚。读者思维，根据待讨论的问题画图。
颜色的用途
颜色使用没有统一的规定，可以根据具体的情况灵活使用。可以用来区分状态，也可以用来区分领域、模块等。如果图中使用了颜色的话，比较好的做法是在某个角落增加颜色说明（如 灰色代表功能未实现等）。
颜色的数量
一张图片中的颜色不宜过多，一般最多不超过3个。颜色过多可能会导致看起来不专业，同时也会让看图的人抓不到重点。如果画图的时候发现要用到很多颜色，可能是把不同层次的问题放到了一张图里，可以根据看图的人确定要讨论的问题然后突出重点。
画里的关系
并不是所有的关系都需要在图里表现，一般只需要表现出重要的关系。有时候系统里的调用关系复杂，全画出来只会让人看的云里雾里抓不到重点。
关系的表现
表现关系的形式有很多，最明显的是在多个角色之间连线，一般连线上要写上文字说明，方便理解，带不带箭头根据实际情况判断。如果关系是简单的关系如并列关系、构成关系等，可以不需要连线，直接用方框的位置来表达。
复杂的关系
如果系统比较复杂，包含的角色特别多关系也特别复杂，可以把角色和关系分开画。有时描述角色的图为了展示系统全貌会加入很多角色，部分角色的关系其实对于本次讨论没有太大的影响。此时可以单独画一张描述关系的图，在图中更加专注核心的角色。
炫酷的图标
有些图画的非常美观，有很多图标。但是大部分情况下，我们用线框图也可以表达出同样的意思。有些图标获取成本比较低且很常用（如服务器、数据库等都是画图工具自带的），用一下也是极好的。
4. 参考资料
公开课：《如何画好架构图》
