工作中，我們經常會發現老闆畫的架構圖，產品經理畫的架構圖，和研發經理髮的架構圖，看起來完全都不一樣，到底誰的是對的？
對於這個問題，我們先來回顧下，架構的定義：
架構，這個詞最早來源於建築工程，後來應用到組織和軟件等各個領域，比如組織架構、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）組件和模塊？
- 模塊：從業務維度上職責的劃分，比如登錄模塊。通常在業務視圖中體現。
- 組件：從物理上或技術上的劃分，更像一個零件。比如我們常說的插件。通常在技術視圖中體現。
所以，在功能相同的情況下，模塊也可能等同於組件。