【架构类】架构图要怎么画

·        

·       1、为什么我们要画架构图？

·       2、架构图从哪里来？

·       3、业务域设计环节的架构图 Gliffy Macro Error Cannot find a diagram with these parameters: Name: 流程图

·       3、技术域设计环节的架构图

·       4、系统架构图部分

o   4.1、UML

o   4.2、五视图法

o   4.3、C4模型法

·       5、如何评判一个架构图的好坏？

o   5.1、从架构的角度判断（SOILD大法好）

o   5.2、从图表的角度

·        

·       6、有哪些好的画图工具

o   6.1、processOn在线绘图工具（推荐度：3星）

·       7、总结

1、为什么我们要画架构图？

架构图在传统的工程、建筑等相对成熟的行业已经非常普及了，比如大家比较熟知的“设计蓝图”以及工业制造中的“三视图”，很难想象如果一个摩天大楼在没有图纸的情况下，最后会成为什么样子。

所以架构图，一方面强迫设计者自身进行架构思路的沉淀与方便他人验收，另一方面解决了从设计思路到制造环节的信息传递的问题。
理解对齐：技术决策需要通过架构描述这种形式被记录和同步，才能让项目组所有成员对整个系统的理解对齐，形成共识；
**言之有物：**架构是在讨论一些较高维技术问题时的必要实物（具体的实物化形式就是所谓架构描述）。否则，要么一堆人对着空气谈（纸上谈兵都说不上），要么每次沟通时都重新找块白板画一画；
**知识沉淀：**架构应该被作为与代码同等重要的文档资产持续沉淀和维护，同时也是项目新人快速理解和上手系统的重要依据。否则，只能靠一些口口相传的残留设计记忆，苦苦维系着项目的生命延续；

2、架构图从哪里来？

架构来源于业务，所有的技术来源都需要体现业务价值，所以设计是从业务设想具象化到落地产品的一个设计过程；

架构的演进思路，尤其是一个大型项目，其实是一个螺旋形的演进路线；从思路上来总结，整个过程更是一个不断拆分的“剥洋葱”的过程：从业务建模的“大局观”去按职责分工拆解成多个子系统、多个子模块、然后在模块能进行细分，层层剥解。
 

3、业务域设计环节的架构图

Gliffy Macro Error
Cannot find a diagram with these parameters:

·       Name: 流程图

步骤一：确定产品方向

• 明确产品用户：谁是我们的主要客户？产品要对客户产生什么价值？
• 核心目标：产品的核心目标是什么（如提升GMV，用户拉新等等）？这个目标如果可以KPI化，建议量化为KPI指标；
• 依赖系统：产品与哪些内外部的系统有依赖和交互的关系？整个产品在系统中的定位是什么？

 
步骤二：确定业务主流程
这一步需要根据产品需求和问题域，按照业务域的流程进行绘制。以一个风控系统为例：

步骤三：业务功能矩阵
通过对业务流程进行分析，根据功能职责，进行垂直分解，识别出业务功能和业务服务，将他们归类到相应的流程节点中去。将业务流程和业务功能点组合成一张业务功能矩阵。这张矩阵图是业务架构中为后续的数据架构、产品架构、技术架构作为重要的输入。

步骤四：明确系统间的边界
1）分层
注重产品功能的枚举、功能模块之间的分界。以业务架构的业务功能矩阵图作为输入，将流程图转换成按节点进行分层，节点的功能点存放在同一层中。同一个产品范围、同一组产品功能的模块放在同一层级，得到一个基础的产品框架。
2）数据流向
产品架构图在表达产品的核心功能外，也应该体现信息流动的路径。当前层级数据的交互形成产品功能，产品功能又产生新的数据，从而推动下一层级的功能运转起来。
如果当前产品的主要使用角色只有一个，则只需要用箭头表明模块间信息流动的方式即可。如果当前产品涉及的角色比较多，则需要用不用颜色的线条将他们和各个模块之间的信息交互关系表示出来。

3、技术域设计环节的架构图

依赖业务域的划分，如果整个组内DDD的思想已经比较浓厚了，我们可以进行后续的动作了，进行技术域的划分，后面直接决定了服务组件以及服务组件内部的构建的划分；
领域
“领域”指的就是一块业务范围；具体来讲，每个组织都有它自己的业务范围和做事方式，这个业务范围以及在其中所进行的活动便是领域。如果你为某个组织开发软件时，你面对的就是这个组织的领域。
业务范围可能也很大，所以我们需要把这个大的业务范围拆开。如果我们把这个范围看成是一个空间的话，那它同时存在“问题空间”和“解决方案空间”。问题空间是从业务需求方面来看，而解决方案空间是从实现软件方面来看。两者是有一些细微的区别的，最终我们用子域来划分问题空间，用限界上下文来划分解决方案空间。
子域
子域是对领域从业务需求方面进行拆分，是逻辑上的。比如一个电商系统，我们可以很明确地可以把它拆分成商品子域、销售子域、仓储子域、客服子域……
子域主要分为三种：
·       核心子域：业务成功的核心竞争力；
·       通用子域：不是核心，但被整个业务系统所使用 ；
·       支撑子域：不是核心，不被整个系统使用，完成业务的必要能力；

举例如下图

 

4、系统架构图部分

4.1、UML

UML的定义：UML是Unified Model Language的缩写，中文是统一建模语言，是由一整套图表组成的标准化建模语言。

类型	名称	用途
结构图	类图	描述系统中对象的类型以及他们之间存在的各种静态关系（泛化、实现、集成等等）
	组件图	系统中组件提供的、需要的接口、端口等，以及它们之间的关系
	对象图	对象图是类图的一个实例，是系统在某个时间点的详细状态的快照
	轮廓图	轮廓图提供了一种通用的扩展机制，用于特定域和平台定制化UML模型
	组合结构图	描述了一个“组合结构”的内部结构，以及它们之间的关系
	部署图	描述了系统内部的软件如何分布在不同的节点上
	包图	系统在包层面上的设计
行为图	用例图	指由抽象者、用例、边界以及它们之间的关系构成的用于描述系统功能的视图
	活动图	描述了具体业务用例的实现流程
	状态机图	描述了对象在它的整个生命周期里，相应不同事件时，执行相关事件的顺序
	序列图	描述了在用例特点场景中，对象如何与其它对象交互
	时序图	时序图是被用来显示随着时间的变化，一个或者多个元素的值或者状态的更改
	交互概念图	交互概览图与活动图相似，但是它的节点是交互图
	通讯图	描述了收发信息的对象的组织关系，强调对象之间的合作关系而不是时间顺序

 
用例图
用例图是指由参与者、用例，边界以及它们之间的关系构成的用于描述系统功能的视图。

用例图中包含以下三种关系：

• 包含关系使用符号《include》，想要查看订单列表，前提是需要先登录。
• 扩展关系使用符号《extend》，基于查询订单列表的功能，可以增加一个导出数据的功能
• 泛化关系，子用例继承父用例所有结构、行为和关系。

 
状态机图
状态机图对一个单独对象的行为建模，指明对象在它的整个生命周期里，响应不同事件时，执行相关事件的顺序。用来表示指定对象，在整个生命周期，响应不同事件的不同状态

序列图
序列图根据时间序列展示对象如何进行协作。它展示了在用例的特定场景中，对象如何与其他对象交互。通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。

 

4.2、五视图法

五视图也就是我们常说的“4+1”视图，通过多种共存的视图描述软件密集型系统的架构。这些视图会基于不同项目干系人（利益相关者）的视点，例如：终端用户、开发者、系统工程师和项目经理。

a、逻辑视图
是所有这些视图中最不可或缺的视图。在很多系统设计中，如果系统的功能、场景等比较清晰（比如有明确协议定义的系统），可能会对用例视图进行简化，但却不可以没有逻辑视图。
主要用途：

• 体现出为终端用户提供什么样的能力
• 系统之间的逻辑分层

关注点：

• 对用户提供的功能；
• 组件之间的职责边界的划分；

举例：

 

b、处理视图
主要用途：
处理流程视图用于描述系统软件组件之间的通信时序，数据的输入输出，反映系统的功能流程 与数据流程,通常由时序图和流程图表示。
举例：

 

c、物理视图
主要用途：

• 体现软件部署到物理设备，软件单元映射到硬件的过程；

关注点：

• 部署硬件设备的可靠性和伸缩性；
• 设备的安全性和通讯的可靠性（如跨机房、跨地域）

举例：

 
d、开发架构
主要用途：
开发视图用于描述系统的模块划分和组成，以及细化到内部包的组成设计，服务于开发人员，反映系统开发实施过程。
这里不仔细展开了，不是说这个图的作用不大，而是工作量太庞大了，需要细化到code级别（真实工作中从来没看人画过）；
举例：

e、场景视图
场景视图，即4+1中的1。从前面的图可以看到，4+1中的4个视图都是围绕着场景视图为核心的。它用于描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计。反映系统的最终需求和交互设计，通常由用例图表示。

4.3、C4模型法

C4模型是我个人比较喜欢和推崇的一种架构绘图方式，它的核心理念是一种“**抽象优先“**的架构制图方法，它也是受前面的 UML 和“4+1”视图模型所启发，但相对而言要更加简单和轻量，只包含少量的一组抽象和图表，很易于学习和使用。
先举个比较现实的例子

 
C4模型通过容器、组件、代码以及人这几个抽象来描述一个软件系统的静态结构，它的核心理念是希望像 Google Map 一样，通过不同层次的细节，为代码建立一种可以放大和缩小的导览图。它最关键的思想就是自顶向下对系统的静态结构进行逐级拆分，依次描述各层次对象的职责、关系和外部依赖。除了核心的层次化静态结构视图，它还可以包含动态视图、部署视图等补充视图。

在C4模型中软件系统被抽象为四个部分：（人）Person、（软件系统）Software System、（容器）Container 和 （组件）Component。

• 人（Person）

这一抽象的提前是软件系统中“人”的部分与”物“分离，例如角色，或者外部子系统等。

• 软件系统（Software System）

软件系统是最高级别的抽象，它描述了一些可以为用户带来价值的东西，无论他们是不是“人”。这包括您正在建模的软件系统，以及该软件系统所依赖的其他软件系统。

• 容器（Container）

容器代表托管代码或数据的事物。为了使整个软件系统正常工作，必须运行一个容器。实际上，容器类似于服务器端的应用程序、一个手机APP，又或者是一个数据库。

• 组件（Component）

“组件”一词在软件开发行业中是一个非常重载的术语，但是在这种情况下，组件只是封装在定义良好的接口后面的一组相关功能。如果您使用的是Java或C＃之类的语言，则想到组件的最简单方法是它是接口后面的实现类的集合。这些组件的打包方式（例如，每个JAR文件，DLL，共享库中的一个组件与许多组件）的打包方式是一个单独且相互关注的问题。

a、第一层：系统上下文
提供了一个展示系统全貌的**顶层大图（big picture）**视角，包括最中心的软件系统、周边的用户以及其他有交互的系统。其中最关键的两个概念分别是：
人（Person）：即使用软件系统的用户，例如一个在线商城系统的消费者、运营小二、系统管理员等；
软件系统（Software System）：作为最高层次抽象，描述了给用户创造价值的软件制品；既包括当前正在设计的软件系统，也包括该系统所依赖（或被依赖）的其他软件系统。一个软件系统通常是由单个软件开发团队所负责。

在绘制系统上下文图时，不需要关心诸如技术栈、协议等任何底层细节。这类图的受众是最广的，因为任何人都可以理解并从中获取到足够的信息，包括技术人员和非技术人员，也包括团队内成员和团队外成员。
b、第二层：容器图
第二层是在第一层的基础上对我们带建设的系统进行了展开，用一个框图来表示，内部可能包括名称、技术选择、职责，以及这些框图之间的交互，如果涉及外部系统，最好明确边界。

c、第三层：组件图

组件图是把某个容器进行展开，描述其内部的模块。
d、第四层：类图

这个就不多说，指导研发同学看的类图，想要画全工作量非常之大。

5、如何评判一个架构图的好坏？

架构图=架构+图表

5.1、从架构的角度判断（SOILD大法好）

---

单一职责：与 Unix 哲学所倡导的“Do one thing and do it well”不谋而合；
开闭原则：用新增（扩展）来取代修改（破坏现有封装），这与函数式的 immutable 思想也有异曲同工之妙；
里式替换：父类能够出现的地方子类一定能够出现，这样它们之间才算是具备继承的“Is-A”关系；
接口隔离：不要让一个类依赖另一个类中用不到的接口，简单说就是最小化组件之间的接口依赖和耦合；
依赖反转：依赖抽象类与接口，而不是具体实现；让低层次模块依赖高层次模块的稳定抽象，实现解耦。

---

正交性：架构同一层次拆分出的各组件之间，应该尽量保持正交，即彼此职责独立，边界清晰，没有重叠。
高内聚：同一组件内部应该是高度内聚的（cohesive），像是一个不可分割的整体（否则就应该拆开）；
低耦合：不同组件之间应该尽量减少耦合（coupling），既降低相互的变化影响，也能增强组件可复用性；
隔离变化：许多架构原则与模式的本质都是在隔离变化 —— 将预期可能变化的部分都隔离到一块，减少发生变化时受影响（需要修改代码、重新测试或产生故障隐患）的其他稳定部分。

5.2、从图表的角度

是否全面
是否全局的表现出了（至少要体现出有关联关系的上下游系统）架构全貌。
命名标准
命名符合行业或者大家公知的命名，望文知意，保证大家的理解是一致的。
分层清晰与层级关系
组件与组件的层级关系如何，哪些是支撑、复用，哪些是业务组件。
图形、标识、图例传达意义清晰

如：随手画了2个方块，为什么是方块而不是其他图形，这2个方块代表什么含义？随手涂鸦的图形会造成理解的混乱；

如：实线、虚线有什么区别？不同颜色的线代表什么？类似的信息第一要严谨，保持同类型的一致；第二是要有图例说明，解释清晰；
进阶要求
好的架构在配色，布局，尺寸，标题（好的架构图让人赏心悦目，差的架构图辣眼睛）也需要注意，尤其是向外部输出的架构图，如技术博客，技术分享（这方面FE同学是专家，可以请教配色问题）

 

 

6、有哪些好的画图工具

6.1、processOn在线绘图工具（推荐度：3星）

是否免费：是（有数量和模板的限制，要升级需要充钱）
类型：线上绘图工具
适用类型：脑图、流程题、鱼骨图、逻辑
地址：[www.processon.com/](https://w…
优点：上手容易，入门简单，基本功能和图形也还ok
缺点：1）在线工具，存储都在云端，所以存在资料泄漏风险；2）创建数量和模板免费版限制比较多，需要花钱；

6.2、[draw.io](draw.io)绘图工具（推荐度：4星）
**是否免费：**个人版免费，企业版收费
类型：线上和桌面2个版本
地址：[drawio-app.com/](https://d…
优点：图形和扩展图形比较多，连线等常规高频动作用起来也比较顺滑；另外提供网页插件版，可以继承到wiki里去（需要收费），支持wiki页面内编辑；
缺点：模板数量比较少

6.3、OmniGraffle（推荐4星）
是否免费：收费（14天免费，觉得好可以支持下）
类型：桌面应用
地址：[www.omnigroup.com/omnigraffle…
优点：快捷键丰富，用的好感觉会非常的顺滑，尤其是配合mac的各种手势；模板比较丰富；
缺点：要钱；一些功能比较鸡肋，比如自动布局；

7、总结

7.1 架构图是架构的直观表达形式之一，它来自于业务的价值诉求；整个架构过程是螺旋式递增的；

 
7.2、推荐的架构如下
复杂的项目，推荐至少有如下几个图
业务方面
描述业务流程：业务流程图
描述功能：产品功能矩阵图
技术方面
描述用户和场景：场景视图
层与层的关系：逻辑视图
数据存储关系：ER关系图
服务/接口之间的关系：处理视图

我们常见的服务分层不清晰和模型膨胀的问题，也需要场景视图和ER关系图来检验；

7.3、 最后，架构图和代码是同等重要的
也许前期没有前期的架构图甚至没有架构的过程能让你更快的进入开发阶段，但后续不仅会带来各种问题，也会让同行对你的能力产生质疑。

最后，祝愿大家在架构之路上越来越精进，也能够产出更好的架构图！感谢大家！