咱们做开发的，日常工作中多多少少都会涉及一些架构设计方面的知识。说到架构设计就不得不提架构图，曾几何时，每一个软件项目都需要一个架构图。但想要画好一张架构图并不容易，一个很简单的架构也可能会出错。你可能曾经也遇到过类似的问题：
在构思架构图的过程中，如何针对当前需求选择合适的架构，如何面向未来，保证架构平滑过渡？
对着画布无从下手、删了又来？
用什么工具画更好？
如何用一张图描述我的系统，并且让产品、运营、开发都能看明白？
图上的框框有点少，是不是要找点儿框框加进来？
（架构图分类）
好的架构图有什么标准吗？俗话说“一图胜千言”，一张好的架构图是不需要过多解释的，它应该是自描述的，并且要具备一致性、健壮性和足够的准确性，能够与代码相呼应。
从一致性上来说，包括结构和语义两个层面。结构外观一致，即方框、形状、边框、线条、颜色等。语义上，所有的架构图与最新的代码变更之间以及架构图与架构图之间都应该定期保持同步，因为一个架构图的变更可能会影响到其他架构图。
除了从 0 构建，架构图的重要挑战往往发生在架构发生重大变化时，如何更新是我们需要思考明白。大多数情况下，根源性的问题并不在于是否使用了一门有效的架构描述语言（比如 UML），而在于低估了架构图的重要性，转而依赖不恰当或不具备一致性的指导性原则，或者缺乏架构思维。
此外，微服务等现代架构的复杂性对架构图同样会产生一些影响，每个微服务都可能有自己的架构图，我们需要关注分布式组件及其类型、组件间的交互方式、生命周期与从属关系。
一张好的架构图确实得费一番功夫，架构图既是专业深度的浓缩体现，也是技术广度的集中呈现。
今天给你推荐一个前阿里 P9 华仔的专题分享——《如何画好一张架构图》，从架构及视图类型、系统序列图、绘制技巧并结合案例一一讲解，360°明晰架构图绘制关键要点。
专题内容介绍
架构图的重要性我就不多啰嗦了，咱们来看看这 3 天的内容，基本上几大架构类别都涉及到了，平时模棱两可以及实操上的难点华仔也会覆盖到。
最后一天的拓展内容会结合案例给大家深入讲解如何在面试或者晋升时候巧妙地展现自己的架构能力。
最近后台经常有人留言问职业选择上的问题，特别突出的就是关于“要不要进大厂”这个问题。
华仔之前说过一句话，我比较认同，进不进大厂不是最重要的，最重要的是要选择一个业务有所发展的企业，这样你的技术积累才可能随着业务量级的增长得到锻炼与提升，也才有动力去学习更好的技术。
经历过技术挑战的人哪儿都挑着要，那时候你的选择权也会越来越多。当然，话说回来，如果你现在没啥选择权，那就踏踏实实学习 - 练习 - 学习 - 练习。