你是否被大廠展示的五花八門，花花綠綠的架構設計圖所深深吸引，當我們想用幾張圖來介紹下業務系統，是不是對著畫布不知從何下手？作為技術扛把子的筒子們是不是需要一張圖來描述系統，讓系統各個參與方都能看的明白？如果有這樣的困惑，本文將介紹一些畫圖的方法論，讓技術圖紙更加清晰。
-
系統架構是概念的體現，是對物/信息的功能與形式元素之間的對應情況所做的分配，是對元素之間的關系以及元素同周邊環境之間的關系所做的定義。
-
架構就是對系統中的實體以及實體之間的關系所進行的抽象描述，是一系列的決策；
-
在TOGAF企業架構理論中， 架構是從公司戰略層面，自頂向下的細化的一部分，從戰略=> 業務架構=>應用/數據/技術架構，當然老板層關注的是戰略與業務架構，我們搬磚的需要聚焦到應用/數據/技術架構這一層。
-
業務架構：由業務架構師負責，也可以稱為業務領域專家、行業專家，業務架構屬于頂層設計，其對業務的定義和劃分會影響組織架構和技術架構。
-
應用架構：由應用架構師負責，需要根據業務場景需要，設計應用的層次結構，制定應用規范、定義接口和數據交互協議等。并盡量將應用的復雜度控制在一個可以接受的水平，從而在快速的支撐業務發展的同時，在保證系統的可用性和可維護性的同時，確保應用滿足非功能屬性的要求如性能、安全、穩定性等。
-
技術架構：描述了需要哪些服務；選擇哪些技術組件來實現技術服務；技術服務以及組件之間的交互關系。
-
數據架構：描述了數據模型、分布、數據的流向、數據的生命周期、數據的管理等關系。
系統架構圖是為了抽象的表示軟件系統的整體輪廓和各個組件之間的相互關系和約束邊界，以及軟件系統的物理部署和軟件系統的演進方向的整體視圖。好的架構圖可以讓干系人理解、遵循架構決策，就需要把架構信息傳遞出去。那么，畫架構圖是為了：解決溝通障礙/達成共識/減少歧義。比較流行的是4+1視圖和C4視圖。
4+1視圖
用于描述系統的參與者與功能用例間的關系，反映系統的最終需求和交互設計，通常由用例圖表示。
用于描述系統軟件功能拆解后的組件關系，組件約束和邊界，反映系統整體組成與系統如何構建的過程，通常由UML的組件圖和類圖來表示。
用于描述系統軟件到物理硬件的映射關系，反映出系統的組件是如何部署到一組可計算機器節點上，用于指導軟件系統的部署實施過程。另外，搜索公眾號互聯網架構師后臺回復“9”，獲取一份驚喜禮包。
用于描述系統軟件組件之間的通信時序，數據的輸入輸出，反映系統的功能流程與數據流程，通常由時序圖和流程圖表示。
開發視圖用于描述系統的模塊劃分和組成，以及細化到內部包的組成設計，服務于開發人員，反映系統開發實施過程。
5種架構視圖從不同角度表示一個軟件系統的不同特征，組合到一起作為架構藍圖描述系統架構。
下面的案例來自C4官網，然后加上了一些筆者的理解。
C4模型使用容器（應用程序、數據存儲、微服務等）、組件和代碼來描述一個軟件系統的靜態結構。這幾種圖比較容易畫，也給出了畫圖要點，但最關鍵的是，我們認為，它明確指出了每種圖可能的受眾以及意義。
1、語境圖（System Context Diagram）
用于描述要我們要構建的系統是什么，用戶是誰，需要如何融入已有的IT環境。這個圖的受眾可以是開發團隊的內部人員、外部的技術或非技術人員。
容器圖是把語境圖里待建設的系統做了一個展開描述，主要受眾是團隊內部或外部的開發人員或運維人員，主要用來描述軟件系統的整體形態，體現了高層次的技術決策與選型，系統中的職責是如何分布的，容器間是如何交互的。
組件圖是把某個容器進行展開，描述其內部的模塊，主要是給內部開發人員看的，怎么去做代碼的組織和構建，描述了系統由哪些組件/服務組成，了組件之間的關系和依賴，為軟件開發如何分解交付提供了框架。
上面的分類是前人的經驗總結，圖也是從網上摘來的，那么這些圖畫的好不好呢？是不是我們要依葫蘆畫瓢去畫這樣一些圖？先不去管這些圖好不好，我們通過對這些圖的分類以及作用，思考了一下，總結下來，我們認為，明確這兩點之后，從受眾角度來說，一個好的架構圖是不需要解釋的，它應該是自描述的，并且要具備一致性和足夠的準確性，能夠與代碼相呼應。
在畫出一個好的架構圖之前， 首先應該要明確其受眾，再想清楚要給他們傳遞什么信息，所以，不要為了畫一個物理視圖去畫物理視圖，為了畫一個邏輯視圖去畫邏輯視圖，而應該根據受眾的不同，傳遞的信息的不同，用圖準確地表達出來，最后的圖可能就是在這樣一些分類里。那么，畫出的圖好不好的一個直接標準就是：受眾有沒有準確接收到想傳遞的信息。
可以看到架構視圖是由方框和線條等元素構成，要利用形狀、顏色、線條變化等區分元素的含義，避免混淆。架構是一項復雜的工作，只使用單個圖表來表示架構很容易造成莫名其妙的語義混亂。
