写在前面：
我是「沸羊羊_」，昵称来自于姓名的缩写 fyy ，之前呕心沥血经营的博客因手残意外注销，现经营此账号。
本人是个小菜，正向着全栈工程师的方向努力着，文章可能并不高产，也很基础，但每写一篇都在用心总结，请大佬勿喷。
如果您对编程有兴趣，请关注我的动态，一起学习研究。
感谢每位读者！
前言
网上关于如何画架构图的实质性资料比较贫瘠，现根据自己画架构图的经验总结一篇文章，读者可以作为参考，相信对于画架构图的新手来说，第一次画往往都不知道如何开始。 读完此文章希望能给读者带来一丝灵感，如有欠缺的地方还望指正。
what?
画架构图之前首先要弄清楚什么是架构图？
软件架构是指软件系统的”基础结构“，创造这些基础结构的准则，以及对这些结构的描述。
个人理解，架构图就是对整个系统的完整的，准确的，宏观的，系统性描述的一种体现方式。是架构师绘制的能帮助用户或者开发者更好的理解系统结构的结构性的体现。
why？
为什么要做？有没有替代方案？
首先，架构图的存在是非常有必要的，不管是前期给用户讲解还是开发前给开发讲解，都是能很清晰的表达系统层次结构的一种方式。当然文档也可以描述这些，但论层次结构的体现，文字的表达是没有图来的清晰明了的。
who？
架构图谁来画？
毋庸置疑，架构师负责画。
when?
什么时候绘制？
不同的图绘制的时间不同。
- 需求分析之后绘制业务架构图
- 开发前绘制技术架构图、运维架构图
- 系统部署上线前，完善运维架构图
how?
架构图如何画？
三种架构图是从不同维度对软件系统进行建模分析的，所以，画法大致上一致，只是角度不同，用途不同，以下的架构图画法适用于三种架构图。
从全局的角度来看架构图
- 整体结构
- 色彩搭配
架构图让读者看到的第一眼，应该给读者留个好印象，从色彩搭配上来看，颜色不超过5个，搭配也不能太跳脱，图的美观设计最起码要符合大众审美。第二眼看的应该是整体结构，整张图一共分为几个层次模块，架构图是不是能清晰的表达模块与模块之间的关系？包括线框的使用，虚线框与实线框的意义是不同的，使用虚线框还是实线框更能准确清晰的表达想要表达的意思。
从局部的角度来看架构图
- 名词表达
- 是否全面
- 模块划分粒度
- 模块摆放是否适合
架构图的名词表达要到位，比如：业务架构图和运维架构图中不能出现技术的字眼。因为不同架构图的读者是不同的，要保证你的读者能迅速的get 到你想表达的意思，这是很重要的。架构图表达的内容是否全面，不管是业务，技术还是运维架构图要表达的内容一定要全面，包括软件系统依赖的第三方服务等都要体现出来。关于架构图中模块的划分粒度，一定要合适，既不能太宽泛，也不能太细粒度，要达到对具体的小功能模块进行一层抽象的粒度即可。包括模块摆放的逻辑是否准确，架构图的每一个模块的摆放，都是有讲究的，要能说出为什么这个模块放在这？放在那行不行？为什么？能回答出这几个问题，相信你的架构图问题不大。
绘制架构图工具
- 推荐：ProcessOn
最后
不管是架构图还是什么图，还是什么事，做完都要能够给别人“讲的明白”，要有足够的理由这样做。———共勉
关于如何绘制架构图，此文章仅是笔者的理解，如有建议与纠正，欢迎交流。