工作中，我们经常会发现老板画的架构图，产品经理画的架构图，和研发经理发的架构图，看起来完全都不一样，到底谁的是对的？
对于这个问题，我们先来回顾下，架构的定义：
架构，这个词最早来源于建筑工程，后来应用到组织和软件等各个领域，比如组织架构、IT架构，数据库架构，等等，他们都有做一个共同的特点，就是结构和愿景。
所以，架构的定义可以概况为：
为了达到某个目标（愿景），将产品分解为一系列组件、模块和交互（结构）。
对同一个目标，不同的人有不同的观察角度，当然就会形成不同的分解方案，这就是所谓的架构视图。理论上观察角度无穷多，架构视图也会无穷，实际上当然不需要那么多。
1、架构视图的分类
基本能满足我们需求的架构视图，可以归结为五种：
应用架构：也叫逻辑架构，关注子系统划分，大功能块。不仅包括用户可见的功能，也包括一些基础模块以及辅助模块。
业务架构：也叫俯视架构，包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。
技术架构：也叫系统架构， 确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系。存储方案及策略。进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。这就是我们通常理解的架构。
代码架构：也叫开发架构，关注程序包，主要为开发人员提供切实可行的指导，不仅包括要编写的程序，还包括可以直接使用的第三方SDK或者现成的框架、类库以及开发的系统将运行于其上的系统软件或者中间件。
部署架构：也叫物理架构，关注‘目标程序及其依赖的运行库和系统软件’最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。
2、架构视图怎么用？
架构即决策。架构需要面向业务需求，并在各种资源（人、财、物、时、事）约束条件下去做权衡、取舍。下面就用一个例子带大家感受不同架构视图在决策过程中的作用。
第一步：确定目标
搬砖的：“头，我们要造什么？”；
设计师：“XXX商城”；
翻译：【目标】比如微博系统
第二步：划分子系统
搬砖的：“图纸画出来了嘛？”；
设计师：“一楼主要以女性消费为主体、二楼以大众娱乐为主体、三楼以美食为主体”；
翻译：【结构】相当于微博系统中的各个子系统，比如评论子系统、动态子系统、消息子系统
注：这相当应用架构，领导更关注的
第三步：划分业务模块
搬砖的：“头，说人话”；
设计师：“一楼有卖衣服、化妆品的，二楼有唱歌、看电影的，三楼有吃的”；
翻译：【模块】按照逻辑区分，比如存储数据模块、搜索模块、消息推送模块
注：这相当于业务架构，产品经理关注的
第四步：划分功能组件
搬砖的：“有没有很知名的店啊？”；
设计师：“有的，一楼有香奈儿、优衣库…、二楼有好乐迪、万达影院…、三楼有海底捞、避风塘…”；
翻译：【组件】比如按存储数据模对应Mysql、搜索对应ElasticSearch、 消息推送对应Kafka
注：这相当于技术架构，码农更关注的
第五步：确定技术路线
搬砖的：“对了，头，商城大门有啥需要叮嘱的施工规范不？或有啥简化施工工艺的新技术嘛？”；
翻译：有框架的可以用吗？
设计师猛吸了一口烟，把烟头扔在地上，用皮鞋左右撵了两下，缓缓从嘴里崩出四个字。
“老样子吧”。
翻译：【框架】Spring全家桶甩起来
注：这相当于代码架构，码农更关注的
第六步：系统如何上线
搬砖的：“头，搞好了商家怎么入住？”；
设计师：“统一装修，统一搬运，拎包入住…哦，错了，搬货入驻”
翻译：【部署】云服务，docker走起来
注：这相当于部署架构，售后更关注的
3、一些概念解释
（1）系统与子系统？
- 系统是由一系列有关联，按特定规则组成的个体，并且产生新的能力。
- 系统与子系统的划分则是观察的角度不同。
需要注意的是，“产生新的能力”，这是系统/子系统和组件/模块的差别。
（2）架构和框架？
- 框架 Framework：关注“规范”，比如MVC、Spring MVC 架构
- Architecture：关注的是“结构”。不同的分解角度，产生不同的架构。
框架是规范也是约束，可以理解为封闭性的话题，定义好，让别人如何去使用，而架构是一种结构，是一种开放性的话题，如何去设计组织架构，如何让架构更具有拓展性，减少沟通错误成
比如大家常用的Spring MVC框架，从开发规范角度，也可以叫做Spring MVC架构，他是一种技术架构的具现。
（3）组件和模块？
- 模块：从业务维度上职责的划分，比如登录模块。通常在业务视图中体现。
- 组件：从物理上或技术上的划分，更像一个零件。比如我们常说的插件。通常在技术视图中体现。
所以，在功能相同的情况下，模块也可能等同于组件。