经常谈架构就会有一种谈虎色变，不敢下手的赶脚；要么就是按照传统写PPT汇报或写投标方案的思路，左右两侧规范机制，中间按照硬件、数据、组件、服务、应用，几个层次划分；都变成八股文了，类似如下：

软件架构设计 电子书 软件架构设计 温昱 pdf_架构设计


基本上在传统IT领域里（做工程项目的），大家看到的架构都是这种模样的。

原因呢也是因为以前的软件工程，都是这种单体应用（没有应用分布式），基本都是这个套路，从水平角度按照传统面向对象三层架构。

所以一说写一个架构图，就基本套用以上的模式，没有几个人能认真思考为什么要弄架构图，到底如何编写？

这块非常认同《软件架构设计》温昱老师编著的书籍，绘制架构必须先弄清楚软件的需求是什么，尤其是软件的关键需求是什么；只有关键的需求才在架构图上体现；这里的架构图指的是概念架构（或者一般都说的总体架构）；
至于大家关注那到底概念架构（总体架构）如何画呢？
这个问题，大家看看架构的分类：五视图法：逻辑架构(应用架构)、开发架构(技术架构)、运行架构、物理架构（部署架构）、数据架构；五个视图的架构都是对概念架构的细化设计。大家理解了这五个视图，就知道咱们一般的架构图总想在一张图里把五个图的部分都放进去；所以要做抽象概括是太难把握这个度了。
所以一般复杂的系统都要从6个架构图的角度去编写，并且子系统很多的时候，应该是针对每个子系统分别进行架构设计【适合系统之间关系不是紧密的场景，比如就是登录用户权限集成和几个接口调用】；这样描述才能清楚的说清楚事情。
五个架构图里比较难理解的是运行架构，运行架构一般就是关键需求或业务的交互逻辑，用序列图或交互调用表达。

该文章描述了架构的技术发展，从单体应用到分布式，再到SOA，最后现在的微服务
https://mp.weixin.qq.com/s/WZn7vBl6Kq4le_pMnY9YSQ 从这里可以看出架构的产生与需求是密不可分；有需求才有架构的模型。