架构图这种装13神器，是不是听起来很高大上的样子？
你是不是以为这些都是架构师，或者非常流弊的技术大佬才能搞的东西？
非也！
其实我们作为产品经理首先应该懂架构图~
然后有一些架构图，也是需要我们产品经理来制作的！
比如我们之前总结过的“业务架构图、功能架构图、产品架构图、信息架构图”。
好了，回到我们本篇文章探讨的核心问题：到底啥是架构图？
其实答案一点都不复杂，很好解释，请看下图：
先别划走，我上面整的这张图，真的不是废话，不信你往下看：
1. 什么是图？
我们先说什么是图，这个比较容易回答。
图是一种信息的表达方式。
就像我们搞PPT时候的有八字真言：“字不如表，表不如图”。
还有一个经典语句，不知道大家听过没有：
“A picture is worth athousand words （一图胜千言）”。
来，让我们把上面说过的话，再说一遍：图是一种信息的表达方式，而且是更好的表达方式。
所以：架构图 = 架构的表达方式
2. 什么是架构？
我们接着说一下，什么是架构。
想彻底搞清楚这个概念啊，我们还得追根溯源一下，long long ago。。。
架构从字面意思上，是源于古代的建筑术语。
（1）架：
“架”就是“加”和“木”的结合，把木头加起来，连接起来就是架。
（2）构：
“构”就是“结构”的意思。
所以，“架构”就是把“木“按照—定的“结构”连接起来。
那“架构图”是什么呢？
结合我们上面说的概念，架构图，那就是把“木“按照—定的“结构”连接起来的一种“表达方式”。
如下图所示，这就是最原始的“架构图”的概念：
我们再举个形象的例子：
比如你有1000亩地，要建一个城市或者说园区。
你是不是第一步就要做一个规划蓝图：划成几块大的区域，修建几条主干路线，以及水电管网怎么铺设……
然后整个工业园区的建设，就在这个基础上展开，这就是架构图的设计。
如果没有架构图的设计，也可以建房子，但建出来的大概就这样子：
架构图设计的好的，建造出来就是这个样子：
好了，我们以上从“不求甚解”的角度，聊了一下啥是架构图。
下面要上干货了。。。觉得无聊的同学，可以划走了。。。
有兴趣的同学，记得准备一瓶水，省的噎着了。。。
1. 架构图的本质
先说结论：架构图的本质是为了管理复杂性！
这句话其实不难理解，让我们回顾一下软件发展的历史，就立马明白了：
面向过程：在软件发展的初期，是没有架构而言的。从最早的汇编语言到过程语言，他们处理的是一个个任务，为此编制了一个个的函数来执行对应的任务。这时候的软件编程语言还是过程语言，所以谈不上架构。
面向对象：随着硬件技术的成熟，能够处理的任务越来越多，为了处理这么多的任务，编程语言也从面向过程转变为面向对象，从而更好的适应任务的发展。软件越来复杂，要处理的任务越来越多，最终导致了系统架构的产生。
结论：架构是在复杂软件结构中产生的，它的任务就是让这些复杂软件中的任务能够互相协作从而来完成共同的任务。系统的架构主要描述的是系统的主要组件和这些组件之间的关系和他们如何进行交互。
2. 架构图的误区
架构图有六大误区，我相信，你在工作的过程中，肯定碰到过！
误区1—架构专门由架构师来做，业务开发人员无需关注
架构的再好，最终还是需要代码来落地，并且组织越大这个落地的难度越大。不单单是系统架构，每个解决方案每个项目也由自己的架构，如分层、设计模式等。如果每一块砖瓦不够坚固，那么整个系统还是会由崩塌的风险。所谓“千里之堤，溃于蚁穴”。
误区2—架构师确定了架构蓝图之后任务就结束了
架构不是“空中楼阁”，最终还是要落地的，但是架构师完全不去深入到第一线怎么知道“地"在哪?怎么才能落的稳稳当当。
误区3—不做出完美的架构设计不开工
世上没有最好架构，只有最合适的架构,不要企图一步到位。我们需要的不是一下子造出一辆汽车，而是从单轮车-->自行车-->摩托车，最后再到汽车。想象一下2年后才能造出的产品，当初市场还存在吗?
误区4—为虚无的未来埋单而过度设计
在创业公司初期，业务场景和需求边界很难把握，产品需要快速迭代和变现，需求频繁更新，这个时候需要的是快速实现。不要过多考虑未来的扩展，说不定功能做完，效果不好就无用了。如果业务模式和应用场景边界都已经比较清晰，是应该适当的考虑未来的扩展性设计。
误区5—味追随大公司的解决方案
由于大公司巨大成功的光环效应，再加上从大公司挖来的技术高手的影响，网站在讨论架构决策时，最有说服力的一句话就成了“淘宝就是这么搞的”或者“腾讯就是这么搞的”。
大公司的经验和成功模式固然重要，值得学习借鉴，但如果因此而变得盲从，就失去了坚持自我的勇气，在架构演化的道路上迟早会迷路。
误区6—为了技术而技术
技术是为业务而存在的，除此毫无意义。在技术选型和架构设计中，脱离网站业务发展的实际，一味追求时髦的新技术，可能会将技术发展引入崎岖小道，架构之路越走越难。考虑实现成本、时间、人员等各方面都要综合考虑，理想与现实需要折中。
3. 架构图的原则
分享、评审、述职、答辩，只要你在互联网这个行业，就几乎离不开要画图。
一提到画图很多人就想站会起来喊，”内卷“、”内卷啦“、”PPT工程师“，但程序代码本身就是一种数学逻辑的具体实现，如果没有一些图表配合文字的阐述，讲真很难让所有人都能在共同的共识下进行交流。
这不像是文科，”八表流云澄夜色，九霄华月动春城“ 上来就能联想到它是在描述啥。但是偏理科代码逻辑或架构设计，只能把抽象的内容用图表的形式展现出来，让大家在同一的共识下共同协同工作。
而我们画的架构图、流程图、结构图、功能图、逻辑图等，都需要遵循以下四原则：
（1）好看：是为了提升沟通效率
（2）好懂：是为了提升交流共识
（3）好用：是为了提升交付质量
（4）好搞：是为了提升实施速度
这就像君子在追求漂亮姑娘一样，好看就想主动撩一下、有品行和共同的三观很快让你开口说我懂你、接下来就是交付质量和实施速度了，那也是水到渠成的事。
其实绘制架构图和我们画原型真的差不多。
你见过哪个高保真原型，是通过axure的原生组件，一个“圆圈”，一个“方块”，一点一点地画出来的？
那不都是用“封装”好的，现成的各种组件，改吧改吧给搞出来的么~
关于“架构图”这玩意，其实也没有多么神秘，也没有多么高大上，最后送给大家一句话：
没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。
