如何画架构图
目录
做一款软件产品，一般要画设计图，常见的有产品图、流程图和架构图。产品图可以看功能和外观，比如页面布局、交互方式和视觉色彩等；流程图可以看基本流程，比如业务流程、计算逻辑、数据流等；架构图有点抽象，主要是看整体结构，比如系统架构、工程架构、算法架构、数据架构等。
产品图和流程图比较直观，而架构图有时候会给人一种花里胡哨的感觉。原因在于，架构图没有严格的定义，也没有统一的标准，表现形式也因人而异。下面说一说我对架构图的理解（仅代表个人观点）。
架构图
先说说架构，它是对具体事物的一个抽象描述。
举个例子，要解释一个软件系统的设计思想，如果对着代码解释，不但效率低，还得让对方懂编程，以及对应的编程语言。更方便的做法是讲结构，不讲细节。用抽象的层次关系（或者模块的组合）来表示一个系统，这就是它的架构。
架构图就是描述架构的示意图，它描述的事物可以是具体的，也可以是抽象的。例如，公司的组织架构是具体的，计算机网络的七层协议是抽象的。
具体怎么画，关键是搞清楚它的目的。比如，给谁看？看什么？
据我观察，架构图主要有如下几个使用场景。
1、向上汇报
要求逻辑正确、结构清晰。不能太简单，否则信息量太少；也不能太复杂，否则细节太多，看起来费劲。架构图的外观和布局要看人下菜，有人喜欢简约，有人喜欢华丽。
2、晋升答辩
架构图作为答辩材料，作用不是给人看懂，而是让人觉得这很厉害。
3、对外宣传
布局和配色要美观，要看起来高大上，从而吸引听众的注意。
4、设计文档
架构图作为设计文档的一部分，是为了让软件的开发和维护更容易。
下面我分享几点画软件架构图的原则。
画图原则
先声明，下面的原则只适用于把架构图当作设计文档的一部分。如果是为了向上汇报、晋升答辩或对外宣传，这些经验不一定适用，或许还会扯你的后腿。
作为目录
我们看书，一般先浏览目录。架构图可以被看成软件系统的目录。看到架构图，可以大致了解系统功能和模块之间的关系。
模块之间的依赖关系，一般用层级表示，即上层依赖下层。
合理抽象
架构图太简单，传递的信息量不足。架构图太复杂，读起来费劲。做好合理的抽象，呈现结构和关系，把细节留给文档。
上图看起来就很复杂，有层次，有嵌套，有横有纵，还有简单的逻辑和解释。不是说复杂不行，而是要想清楚是否有必要。
重点突出
软件项目如果涉及多个职能，建议使用多个架构图，比如画出系统架构、工程架构、算法架构、数据架构等。做好抽象和分类，能让人快速理解项目结构和分工。
上图是 tensorflow 的架构图，虽然不美观，但表达清晰。底层是 C 语言，封装成 C++、Python 接口给用户调用；支持分布式计算、并且适配计算硬件和网络。
总结
架构体现的是对系统的理解，不分好坏，不分贵贱。而是要看，最后实现的系统是否能有效解决问题。架构图作为设计文档的一部分，它的主要作用是帮助大家理解这个系统，从而降低软件的研发和维护成本。把它画成什么样不重要，重要的是让人看懂。