前言
借用本篇软文与大家共享，那些高大上的系统架构图是如何画出来的，如何画更加优秀。
何为架构
聊到架构图这个话题，不去聊聊何为架构，我觉得是极其不负责任的。都不清楚，何为架构，那么架构图画出来，代表什么，完全属于没有意义的存在。
那么，何为架构？相信提到这个话题，某些大佬，开始在思考，那些年看到过得那些解释、那些系统发展的历史、那些点滴的理论。
是的，总离不开那些话题，但是今天，我不再赘述前人的优秀总结。谈点个人的想法。
个人觉得，不用想的太高大上，高大上的理论，请移步至《架构师教程》--咱们国家架构师考试中的指南书籍。
“架构”，即架设、构建。完成对于平台的合理架设，包括其首当其冲的可用，到可扩展、容易被开发、产品、业务、销售等全面接受的一个整体的设计。
完成对于平台的完备构建，是指，将设计好的、开发好的平台，能够有容器展示其本色。英雄本色，不能让英雄落寞。找一个最好的场地，展示其能力，构建出一个
完备性的平台。综合两点，即可以是一个好的架构。
架构图分类
如果你深深地理解了，我说的架构含义。那综合起来，一句话，架构图，就是把你做的架设与构建，反馈给开发、产品、销售等等所以平台、系统参与的角色看的一个展示。
让不同的角色，能够清晰看到、清晰地理解，这就是最优秀的架构图。
好的，那么，我们再来说说架构图分类。上边说了，不同的角色都要看架构图，那么，肯定架构图是有分类的。一个合格的架构师，不能把一堆技术堆叠出来的图或者文字，扔给销售，
那无疑，是要挨揍的。
开发人员
作为一名开发，参与到一个新的团队、一个新的项目中，满脸问号。需要给开发人员培训的内容或者告诉开发人员的，包括：当前项目或者平台，是有什么业务逻辑，有哪些业务模块，个人负责哪个模块，整体使用了什么样的技术，需要个人掌握哪些技能，会学到哪些技能，在模块中技术的实现等等。
那么，咱们先不关心具体架构图都有哪些，回归到架构图中，看起来可能架构师要为开发人员提供技术架构实现的图示展示、业务模块、系统功能的图示展示。
产品或销售或领导
作为一名产品或者销售，更关心的是整体平台或者系统，目前有的功能、实现、待实现的规划等等。
那么，可能也需要业务模块、系统模块的图示展示。
运维人员
作为一名运维，需要搞清楚的是系统如何部署、如何排查模块问题、系统构建问题（环境等）等等。
那么，可能需要提供部署架构等的图示展示。
我们简单的归结了三类人员，一个平台或者系统建设可能会有更多的参与角色，我们不多讲，大致上，也是上述的图示即可。
常规意义上，归结架构图分类大致如下：
- 系统架构
- 应用架构
- 业务架构
- 客户端架构
- 前端架构
- 部署架构
- 领域架构
画好架构图，是一个合格架构师的基本素养，对于上述分类，也只是从某种角度，进行常规划分。可能还会有，更多的展示，比如技术架构、功能架构等等名词
架构图历史
讲架构图分类时，我们聊了，不同角色得所需。那么，其实这个来源于架构图最早的思想---4+1架构视图。
4+1 架构视图，由1995年提出，
逻辑视图：系统提供给用户的功能
开发视图：程序员角度看系统的逻辑组成
物理视图：系统工程师角度看系统的物理构成
处理视图：系统的业务逻辑处理过程
场景视图：用户角度看系统实现的需求功能
4+1架构视图，因为绑定UML图，对于一些不专业人员，理解难，所以国内很少使用。同时，逻辑视图、开发视图、处理视图，也比较容易混淆。
架构图分类解析
上述我们聊了这么多，那么常规意义的架构分类，是如何区分的呢？是根据不同方式划分而来。
按照业务划分，业务架构
按照领域划分，领域架构（包含后端、客户端、前端）
按照客户端模块划分，客户端架构
按照后端模块划分，系统架构
按照后端应用划分，应用架构
按照后端组件划分，部署架构
按照前端模块划分，前端架构
业务架构
定义系统，提供的业务功能
系统架构
定义系统后端系统，又称技术架构，功能架构，描述系统中后端使用的技术、模块功能
应用架构
定义后端系统由那些应用构成
前端架构
定义前端技术，描述系统中前端实现中的功能
部署架构
定义后端应用部署情况
最后的最后
详细的展示了，各种架构的分类，以及其代表的内容。那么，足够理解之后，才能画出优秀的架构图。加油吧，架构师们！！
