欢迎关注方志朋的博客，回复”666“获面试宝典
 

  
作者：三画
  
简介：阿里巴巴技术专家，梓敬、鹏升和余乐对此文亦有贡献。三画曾多年从事工作流引擎研发工作，现专注于高并发移动互联网应用的架构和开发。
 
 
技术传播的价值，不仅仅体现在通过商业化产品和开源项目来缩短我们构建应用的路径。加速业务的上线速率，也体现在优秀工程师的工作效率提升、产品性能优化和用户体验改善等经验方面的分享，以提高我们的专业能力。
 
接下来，阿里巴巴技术专家三画，将分享自己和团队在画好架构图方面的理念和经验，希望对你有所帮助。当我们想用一张或几张图来描述我们的系统时，是不是经常遇到以下情况：
 

  
对着画布无从下手、删了又来?如何用一张图描述我的系统，并且让产品、运营、开发都能看明白?画了一半的图还不清楚受众是谁?画出来的图到底是产品图功能图还是技术图又或是大杂烩?图上的框框有点少是不是要找点儿框框加进来?布局怎么画都不满意…
 
 
如果有同样的困惑，本文将介绍一种画图的方法论，来让架构图更清晰。
 
先厘清一些基础概念
 
什么是架构?
 
架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是一系列的决策。
 
架构是结构和愿景。系统架构是概念的体现，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。
 
做好架构是个复杂的任务，也是个很大的话题，本篇就不做深入了。有了架构之后，就需要让干系人理解、遵循相关决策。
 
什么是架构图?
 
系统架构图是为了抽象地表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。
 
架构图的作用
 
一图胜千言。要让干系人理解、遵循架构决策，就需要把架构信息传递出去。架构图就是一个很好的载体。
 
那么，画架构图是为了：
 
解决沟通障碍
达成共识
减少歧义
 
架构图分类
 
搜集了很多资料，分类有很多，有一种比较流行的是 4+1 视图，分别为场景视图、逻辑视图、物理视图、处理流程视图和开发视图。
 
场景视图
 
场景视图用于描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计，通常由用例图表示。
 
 
 
逻辑视图
 
逻辑视图用于描述系统软件功能拆解后的组件关系，组件约束和边界，反映系统整体组成与系统如何构建的过程，通常由 UML 的组件图和类图来表示。
 
 
 
物理视图
 
物理视图用于描述系统软件到物理硬件的映射关系，反映出系统的组件是如何部署到一组可计算机器节点上，用于指导软件系统的部署实施过程。
 
 
 
处理流程视图
 
处理流程视图用于描述系统软件组件之间的通信时序，数据的输入输出，反映系统的功能流程与数据流程，通常由时序图和流程图表示。
 
 
 
开发视图
 
开发视图用于描述系统的模块划分和组成，以及细化到内部包的组成设计，服务于开发人员，反映系统开发实施过程。
 
 
 
以上 5 种架构视图从不同角度表示一个软件系统的不同特征，组合到一起作为架构蓝图描述系统架构。
 
怎样的架构图是好的架构图
 
上面的分类是前人的经验总结，图也是从网上摘来的，那么这些图画的好不好呢?是不是我们要依葫芦画瓢去画这样一些图?
 
先不去管这些图好不好，我们通过对这些图的分类以及作用，思考了一下，总结下来。
 
我们认为，在画出一个好的架构图之前， 首先应该要明确其受众，再想清楚要给他们传递什么信息 。
 
所以，不要为了画一个物理视图去画物理视图，为了画一个逻辑视图去画逻辑视图，而应该根据受众的不同，传递的信息的不同，用图准确地表达出来，最后的图可能就是在这样一些分类里。
 
那么，画出的图好不好的一个直接标准就是：受众有没有准确接收到想传递的信息。
 
明确这两点之后，从受众角度来说，一个好的架构图是不需要解释的，它应该是自描述的，并且要具备一致性和足够的准确性，能够与代码相呼应。
 
画架构图遇到的常见问题
 
方框代表什么?
 
 
 
为什么适用方框而不是圆形，它有什么特殊的含义吗?随意使用方框或者其他形状可能会引起混淆。
 
虚线、实线什么意思?箭头什么意思?颜色什么意思?
 
 
 
随意使用线条或者箭头可能会引起误会。
 
运行时与编译时冲突?层级冲突?
 
 
 
架构是一项复杂的工作，只使用单个图表来表示架构很容易造成莫名其妙的语义混乱。
 
本文推荐的画图方法
 
 
 
C4 模型使用容器(应用程序、数据存储、微服务等)、组件和代码来描述一个软件系统的静态结构。
 
这几种图比较容易画，也给出了画图要点，但最关键的是，我们认为，它明确指出了每种图可能的受众以及意义。
 
下面的案例来自 C4 官网，然后加上了一些我们的理解，来看看如何更好的表达软件架构。
 
语境图(System Context Diagram)
 
 
 
这是一个想象的待建设的互联网银行系统，它使用外部的大型机银行系统存取客户账户、交易信息，通过外部电邮系统给客户发邮件。
 
可以看到，非常简单、清晰，相信不需要解释，都看的明白，里面包含了需要建设的系统本身，系统的客户，和这个系统有交互的周边系统。
 
这样一个简单的图，可以告诉我们，要构建的系统是什么;它的用户是谁，谁会用它，它要如何融入已有的 IT 环境。
 
这个图的受众可以是开发团队的内部人员、外部的技术或非技术人员。即：
 
构建的系统是什么
谁会用它
如何融入已有的 IT 环境
 
怎么画?中间是自己的系统，周围是用户和其他与之相互作用的系统。这个图的关键就是梳理清楚待建设系统的用户和高层次的依赖，梳理清楚了画下来只需要几分钟时间。
 
容器图(Container Diagram)
 
容器图是把语境图里待建设的系统做了一个展开。
 
 
 
上图中，除了用户和外围系统，要建设的系统包括一个基于 Java\Spring MVC的 Web 应用提供系统的功能入口，基于 Xamarin 架构的手机  App 提供手机端的功能入口，一个基于 Java 的 API 应用提供服务，一个 MySQL 数据库用于存储，各个应用之间的交互都在箭头线上写明了。
 
看这张图的时候，不会去关注到图中是直角方框还是圆角方框，不会关注是实线箭头还是虚线箭头，甚至箭头的指向也没有引起太多注意。
 
我们有许多的画图方式，都对框、线的含义做了定义，这就需要画图的人和看图的人都清晰的理解这些定义，才能读全图里的信息。
 
而现实是，这往往是非常高的一个要求，所以，很多图只能看个大概的含义。
 
这个图的受众可以是团队内部或外部的开发人员，也可以是运维人员。用途可以罗列为：
 
展现了软件系统的整体形态。
体现了高层次的技术决策。
系统中的职责是如何分布的，容器间是如何交互的。
告诉开发者在哪里写代码。
 
怎么画?用一个框图来表示，内部可能包括名称、技术选择、职责，以及这些框图之间的交互，如果涉及外部系统，最好明确边界。
 
组件图(Component Diagram)
 
 
 
组件图是把某个容器进行展开，描述其内部的模块。
 
这个图主要是给内部开发人员看的，怎么去做代码的组织和构建。其用途有：
 
描述了系统由哪些组件/服务组成
厘清了组件之间的关系和依赖
为软件开发如何分解交付提供了框架
 
类图(Code/Class Diagram)
 
 
 
这个图很显然是给技术人员看的，比较常见，就不详细介绍了。
 
案例分享
 
下面是内部的一个实时数据工具的架构图。作为一个应该自描述的架构图，这里不多做解释了。如果有看不明白的，那肯定是还画的不够好。
 
 
 
画好架构图可能有许多方法论，本篇主要介绍了 C4 这种方法，C4 的理论也是不断进化的。
 
但不论是哪种画图方法论，我们回到画图初衷，是为了更好的交流，我们在画的过程中不必被条条框框所限制。简而言之，画之前想好：画图给谁看，看什么，怎么样不解释就看懂。
 
画图的工具有：
 
Keynote
Xmind
EdrawMax
Visio
OmniGraffle
Process On
 
文中物理视图 Download 地址：
 
Win：http://t.cn/EXAGBDW
Mac：http://t.cn/EXAqtxI
 
（感谢阅读，希望对你所有帮助)
 
来源：https://www.easemob.com/news/2767
 

 
热门内容：
 
MySQL 8.0 可以操作 JSON 了，牛逼。。。
如何写出让同事无法维护的代码？
抖音的服务器究竟有多大？
重磅消息：Spring 6 和Spring Boot 3
有个程序员老公有多爽？？？

 

 

 
最近面试BAT，整理一份面试资料《Java面试BAT通关手册》，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。
获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。
 
明天见(｡･ω･｡)ﾉ♡
 

一、前言
 
很多程序员画架构图头疼，不知道画什么、怎么画！
 
分享、评审、述职、答辩，只要你在程序员这个行业，就几乎离不开要画图。
 
一提到画图很多人就想站会起来喊，”内卷 “、” 内卷啦“、”PPT 工程师“，但程序代码本身就是一种数学逻辑的具体实现，如果没有一些图表配合文字的阐述，讲真很难让所有人都能在共同的共识下进行交流。
 
这不像是文科，” 八表流云澄夜色，九霄华月动春城 “ 上来就能联想到它是在描述啥。但是偏理科代码逻辑或架构设计，只能把抽象的内容用图表的形式展现出来，让大家在同一的共识下共同协同工作。
 
而我们画的架构图、流程图、结构图、功能图、逻辑图等，都需要好看、好懂、好用、好搞，因为：
 
好看是为了提升沟通效率，
好懂是为了提升交流共识，
好用是为了提升交付质量，
好搞是为了提升实施速度。
这就像君子在追求漂亮姑娘一样，好看就想主动撩一下、有品行和共同的三观很快让你开口说我懂你、接下来就是交付质量和实施速度了，那也是水到渠成的事。
 
好，别激动，接下来我们就开始专心研究研究架构图，都有哪些，该怎么画，有什么手法。
 
二、架构图有哪几种？
 
仅说技术架构图的话，通常我们☞指的是选型各项技术组件来支撑整个服务建设的系统架构。但用于不同人群范围和不同场景下会有其他分类，如图 26-1 架构图分类
 
 
 
 
业务架构：需求初期业务的结果和过程描述一般比较模糊，可能来自于某个老板、运营或用户的反馈。客户说海尔洗衣机洗土豆会堵，海尔立马设计专门的土豆洗衣机 业务方向往往是定方向和结果的叫战略，主要包括业务规划、业务模块和流程以及问题域的列表等。
应用架构：服务复用、跨组协同，简单、灵活、整合是应用架构必须考虑的点，就像你要上线一个聊天功能，那么聊天内容的输入法、文字识别、舆情监控以及视频服务、支付服务等，它们都是在应用架构分层下沉淀到平台的产物，在供各个方使用。
产品架构：业务提需求，产品定方案，相对于业务的粗放流程，产品架构会更加细腻以及考虑各个模块的分层和边界。
数据架构：数据的获取、数据的存放和数据的使用是数据架构要解决的三个问题，数据库存放、大数据汇总、数据分析等。
技术架构：是离程序员最近的架构设计，它不仅是系统搭建的架构图设计，还包括了结构、功能、流程、逻辑等内容。它的具体描述就是整个系统如何落地的具体实现方案。
三、Zachman 框架是什么？
 
Zachman 框架，由约翰 扎科曼（John Zachman ）在 1987 年创立的全球第一个企业架构理论，其论文《信息系统架构框架》至今仍被业界认为是企业架构设计方面最权威的理论。
 
Zachman 框架（Zachman framework）是一种逻辑结构，它可以对企业信息按照不同分类和不同角度进行表示。
 
Zachman 框架，从横向六个角度看待企业，这个六个观点可以分为；什么内容、如何工作、什么地点、谁负责、为什么这么做（称为 W5H）。
 
框架的列由一组工件组成，分为规划者、拥有者、设计者（架构师）、建造者、分包者、产品，或者有时表示为视点：范围上下文，业务概念，系统逻辑，技术，物理，组件组装和操作类。整体如图 26-2 TOGAF Zachman 框架
 
 
 
 
表格横向六项 代表了用于描述信息系统的某一个方面，对于任何一个事物只要在这几个基本方面对其进行清洗的解释就足够可以描述清楚。
 
数据（What，即什么内容）：什么是业务数据，信息或对象？
功能（How，即如何工作）：业务如何运作，即什么是业务流程？
网络（Where，即何处）：企业运营、部署在哪里？
人（Who，即何人负责）：什么人？什么是业务部门及其等级制度？
时间（When，即什么时间）：业务计划和工作流程是什么？什么时候执行？
原因（Why，即为什么做）：为什么选择的解决方案？这是怎么产生的？
表格纵向六项 代表了在信息系统构造过程中所涉及到的人在描述信息系统时所采用的视角，包括：
 
范围 / 规划者（Planner）：此视图描述了业务目的和策略，充当其他视图将被派生和管理的上下文。
业务模型 / 拥有者（Owner）：这是对信息系统必须在其中运作的组织的描述。
系统模型 / 设计师（Designer）：该视图概述了系统如何满足组织的信息需求。
技术模型 / 建造者（Builder）：这是系统如何实施的表示，它使特定的解决方案和技术显而易见。
详细表述 / 分包者（Sub-Contractor）：这些表示说明了某些系统元素的特定于实现的细节：在生产开始之前需要进一步说明的部分。
功能系统 / 产品（Functioning Enterprise）：在 1987 年的论文（《A framework for information systems architecture》）中并没有这一行的内容，实际上此行的内容也并不在架构描述的范畴的之内，不过为了使得架构 Zachman 框架对于架构的表述更加完备，这一行最终还是被加了进去。
根据 TOGAF 的定义，企业是具有一系列共同目标组织的集合，而架构则是为了有效地实现这一系列目标。
 
在实现的过程中 定义了企业的结构和运作模式的概念蓝图（SearchCIO），以及构成企业的所有关键元素和其关系的综合描述（Zachman）。通过创建、沟通和优化用以描述企业未来状态和发展的关键原则和模型以将业务愿景和战略转化成有效的企业变更的过程（Gartner）。
 
可以这一部分内容会比较绕，但可以作为架构设计的知识扩展进行学习理解以及运用。
 
四、陪你画个架构图
 
简单来说，架构图就是为了达成交流共识的实现方案演示，并不一定非得拘泥于某种形式，只要你能画的清楚，讲的明白就最合适不过了。
 
1. 架构选型图
 
 
 
 
难度：⭐⭐⭐
作用：通常在新项目开发初期，都要做一些技术选型工作。在负载、网关、架构、治理、框架、服务、数据以及环境和支撑服务上，要选择适合当前开发的技术。
2. 微服务架构
 
 
 
 
难度：⭐⭐⭐⭐
作用：技术选型完毕后，接下来就是对于这些技术的运用。这个过程有点像搭积木一样，把每一个区域用适合此位置的积木填充进去。如果是团队初建或者是技术升级，那么这个过程还是比较复杂的，需要大量的验证。不过其实互联网的技术分层和使用已经相对稳定，搭建一个这样的微服务并不会耗费太长的时间。
3. 技术架构图
 
 
 
 
难度：⭐⭐⭐⭐
作用：技术架构图主要是对于研发层面做技术实现指导的，它可以把系统分层和实现结构划分清楚。另外一般也会把案例工程的结构拿出来一起讲解，这样可以让团队伙伴快速的进入开发。
五、总结
 
本章节向大家讲解了什么是架构图，架构图的分类和怎么画架构图，通过这样的内容可以让大家对架构图有一个全貌的认知。在以后自己画架构图了也可以非常明确的知道面对的什么用户群体，要画的内容是什么。
TOGAF 有一套非常完善的企业架构理论，它描述了一种开发和管理企业体系结构生命周期的方法，并构成了 TOGAF 的核心。所涉及到的知识非常丰富，值得认真看一下。
好看，能把一件事做的好看非常重要，好看能让人提起兴趣、好看可以使沟通成本降低。也鼓励大家尽可能把经过自己手里的东西，做的好看一些。

 
 
前言

 
前两天群里有人问，架构图到底怎么画，能不能发来研究一下？手上的架构图其实挺多的，但是大多都涉密，不太方便拿出来。
 
不过网上公开的资料到处都是啊，随手搜罗几张来给大家分享一下，共3招，告诉你架构图到底怎么画。
 
照例，文末有扩展资料下载。
 
声明：以下所有图都来自于百度图片。
 
第一招：分层
 
其实分层不是架构图的特点，而是架构的特点。架构的核心奥义就是分层，分层的目的是为了解耦。
 
比如最早的MVC模式，即Model-View-Controller(模型-视图-控制器) 模式既是如此。
 
但是分层不宜过多，一般最多 7层，倒不是有啥明文规定，而是层数太多了，你就没办法看了，可读性太差。
 
比如下面这个，分5层：接入层、展现层、应用层、支撑层、基础层。
 

 
这几层各司其职，就像公司的各个部门一样。其中具体的内容我们不需要仔细研究哈，简单了解分层逻辑就行了。
 
需要注意的是，系统架构中需要注明跟内外部系统的交互，比如上图中右侧的部分就是了。
 
第二招：切分

 
分层是横向分割，切分是纵向切割。我感觉“切分”这个词不太好，感觉“劈开”更形象。
 
比如下图，核心业务层，就是劈开了。每一个业务模块都有自己的功能、数据库，都是单独的MCV模式。
 

 
把一个单体架构，按照切分的逻辑给纵向切出来，其实就是大名鼎鼎的“SOA”了。有些人说SOA已经过时了，其实不完全是哈。
 
无论什么结论，都不能脱离前提。如同“抛开剂量谈毒性都是耍流氓”一样，“脱离业务场景谈架构也是耍流氓”。
 
能解决问题就好了，你一个30人的公司，搞什么业务中台、数据中台？一个3岁的娃娃谈什么青龙偃月刀？那是活腻歪了，找死呢。
 
第三招：抽象
 
抽象很容易理解哈，简单来说就是提取公因式，复杂一点来说就是升维。比如张三和李四抽象一下就是男人；张三和王大妈可以抽象成中国人；张三和Lisa可以抽象成人。

 

 
上图中，就是“抽象”的典型代表。业务中台其实就是把各个系统中都需要用的东西抽象一层出来就好了。
 
这个是阿里的业务中台架构，这张图中所有的功能都不是单独定制的，全部是其他各个系统公用的部分。

 
所以中台的架构图其实挺好画的，你有多少个系统，其中有多少“公因式”，把他们抽象出来就行了。
 
结语

 
扩展阅读：【15】份架构图、架构优化相关文档。公众号“大数据架构师”后台回复“架构图”即可下载。
 
注意事项：资料发文一周后自然失效，请尽快转存。一周后可以点击“阅读原文”，直通知识星球获取。

 

 
加油，数字人，今天又是美好的一天！
 
感谢阅读，本次分享的内容就结束了。也欢迎大家加我微信，咱俩私聊啊

 

 
推荐阅读：

 
架构师必看：架构设计的四大思维支柱

 
技术文档中的各种架构图该怎么画？ 

 
实时数仓架构设计与选型

 
一口气说穿数据中台-给你架构师的视角

 
一口气说透中台--给你架构师的视角

 
更多精彩：
 

 
 
点击上方[全栈开发者社区]→右上角[...]→[设为星标⭐]
 

  
技术传播的价值，不仅仅体现在通过商业化产品和开源项目来缩短我们构建应用的路径，加速业务的上线速率，也体现在优秀工程师在工作效率提升、产品性能优化和用户体验改善等经验方面的分享，以提高我们的专业能力。
 
 
本文作者阿里巴巴技术专家三画，分享了自己和团队在画好架构图方面的理念和经验，首发于阿里内部技术分享平台，阿里巴巴中间件授权转载，梓敬、鹏升和余乐对此文亦有贡献。
 
当我们想用一张或几张图来描述我们的系统时，是不是经常遇到以下情况：
 
对着画布无从下手、删了又来？
用一张图描述我的系统，并且让产品、运营、开发都能看明白？
画了一半的图还不清楚受众是谁？
画出来的图到底是产品图功能图还是技术图又或是大杂烩？
图上的框框有点少是不是要找点儿框框加进来？
布局怎么画都不满意……
 
如果有同样的困惑，本文将介绍一种画图的方法论，来让架构图更清晰。
 
先厘清一些基础概念
 

 
1、什么是架构
 
架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是一系列的决策。
 
架构是结构和愿景。
 
系统架构是概念的体现，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。
 
做好架构是个复杂的任务，也是个很大的话题，本篇就不做深入了。有了架构之后，就需要让干系人理解、遵循相关决策。
 
2、什么是架构图
 
系统架构图是为了抽象的表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。
 
3、架构图的作用
 
一图胜千言。要让干系人理解、遵循架构决策，就需要把架构信息传递出去。架构图就是一个很好的载体。那么，画架构图是为了：
 
解决沟通障碍
达成共识
减少歧义
 

 
4、架构图分类
 
搜集了很多资料，分类有很多，有一种比较流行的是4+1视图，分别为场景视图、逻辑视图、物理视图、处理流程视图和开发视图。
 
场景视图
 
场景视图用于描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计，通常由用例图表示。
 
 

 
逻辑视图
 
逻辑视图用于描述系统软件功能拆解后的组件关系，组件约束和边界，反映系统整体组成与系 统如何构建的过程,通常由UML的组件图和类图来表示。
 
 

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

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

 
开发视图
 
开发视图用于描述系统的模块划分和组成，以及细化到内部包的组成设计，服务于开发人员，反映系统开发实施过程。
 
 

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

 
上面的分类是前人的经验总结，图也是从网上摘来的，那么这些图画的好不好呢？是不是我们要依葫芦画瓢去画这样一些图？
 
先不去管这些图好不好，我们通过对这些图的分类以及作用，思考了一下，总结下来，我们认为，在画出一个好的架构图之前， 首先应该要明确其受众，再想清楚要给他们传递什么信息 ，所以，不要为了画一个物理视图去画物理视图，为了画一个逻辑视图去画逻辑视图，而应该根据受众的不同，传递的信息的不同，用图准确地表达出来，最后的图可能就是在这样一些分类里。那么，画出的图好不好的一个直接标准就是：受众有没有准确接收到想传递的信息。
 
明确这两点之后，从受众角度来说，一个好的架构图是不需要解释的，它应该是自描述的，并且要具备一致性和足够的准确性，能够与代码相呼应。
 
画架构图遇到的常见问题
 

 
1、方框代表什么？
 
 

 
为什么适用方框而不是圆形，它有什么特殊的含义吗？随意使用方框或者其它形状可能会引起混淆。
 
2、虚线、实线什么意思？箭头什么意思？颜色什么意思？
 
 
随意使用线条或者箭头可能会引起误会。
 
3、运行时与编译时冲突？层级冲突？
 
 
架构是一项复杂的工作，只使用单个图表来表示架构很容易造成莫名其妙的语义混乱。
 
本文推荐的画图方法
 

 
 

 C4 模型使用容器（应用程序、数据存储、微服务等）、组件和代码来描述一个软件系统的静态结构。这几种图比较容易画，也给出了画图要点，但最关键的是，我们认为，它明确指出了每种图可能的受众以及意义。
 
下面的案例来自C4官网，然后加上了一些我们的理解，来看看如何更好的表达软件架构
 
1、语境图(System Context Diagram)
 
 

 
这是一个想象的待建设的互联网银行系统，它使用外部的大型机银行系统存取客户账户、交易信息，通过外部电邮系统给客户发邮件。可以看到，非常简单、清晰，相信不需要解释，都看的明白，里面包含了需要建设的系统本身，系统的客户，和这个系统有交互的周边系统。
 
用途
 
这样一个简单的图，可以告诉我们，要构建的系统是什么；它的用户是谁，谁会用它，它要如何融入已有的IT环境。这个图的受众可以是开发团队的内部人员、外部的技术或非技术人员。即：
 
构建的系统是什么
谁会用它
如何融入已有的IT环境
 
怎么画
 
中间是自己的系统，周围是用户和其它与之相互作用的系统。这个图的关键就是梳理清楚待建设系统的用户和高层次的依赖，梳理清楚了画下来只需要几分钟时间。
 
2、容器图(Container Diagram)
 
容器图是把语境图里待建设的系统做了一个展开。
 
 

 
上图中，除了用户和外围系统，要建设的系统包括一个基于java\spring mvc的web应用提供系统的功能入口，基于xamarin架构的手机app提供手机端的功能入口，一个基于java的api应用提供服务，一个mysql数据库用于存储，
 
各个应用之间的交互都在箭头线上写明了。
 
看这张图的时候，不会去关注到图中是直角方框还是圆角方框，不会关注是实线箭头还是虚线箭头，甚至箭头的指向也没有引起太多注意。
 
我们有许多的画图方式，都对框、线的含义做了定义，这就需要画图的人和看图的人都清晰的理解这些定义，才能读全图里的信息，而现实是，这往往是非常高的一个要求，所以，很多图只能看个大概的含义。
 
用途
 
这个图的受众可以是团队内部或外部的开发人员，也可以是运维人员。用途可以罗列为：
 
展现了软件系统的整体形态
体现了高层次的技术决策
系统中的职责是如何分布的，容器间的是如何交互的
告诉开发者在哪里写代码
 
怎么画
 
用一个框图来表示，内部可能包括名称、技术选择、职责，以及这些框图之间的交互，如果涉及外部系统，最好明确边界。
 
3、组件图(Component Diagram)
 
 

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

 
这个图很显然是给技术人员看的，比较常见，就不详细介绍了。
 
案例分享
 

 
下面是内部的一个实时数据工具的架构图。作为一个应该自描述的架构图，这里不多做解释了。如果有看不明白的，那肯定是还画的不够好。
 
 

 
画好架构图可能有许多方法论，本篇主要介绍了C4这种方法，C4的理论也是不断进化的。但不论是哪种画图方法论，我们回到画图初衷，更好的交流，我们在画的过程中不必被条条框框所限制。简而言之，画之前想好：画图给谁看，看什么，怎么样不解释就看懂。
 
参考资料：
 
C4官网：
 
https://c4model.com/
 
为什么需要软件架构图：
 
https://www.infoq.cn/article/GhprrUlOYyOqS8*FR1pH
 
觉得本文对你有帮助？请分享给更多人

关注「全栈开发者社区」加星标，提升全栈技能
本公众号会不定期给大家发福利，包括送书、学习资源等，敬请期待吧！
如果感觉推送内容不错，不妨右下角点个在看转发朋友圈或收藏，感谢支持。
好文章，留言、点赞、在看和分享一条龙吧❤️