技術傳播的價值，不僅僅體現在通過商業化產品和開源項目來縮短我們構建應用的路徑，加速業務的上線速率，也體現在優秀工程師在工作效率提升、產品性能優化和用戶體驗改善等經驗方面的分享，以提高我們的專業能力。
當我們想用一張或幾張圖來描述我們的系統時，是不是經常遇到以下情況：
- 對著畫布無從下手、刪了又來？
- 如何用一張圖描述我的系統，並且讓產品、運營、開發都能看明白？
- 畫了一半的圖還不清楚受眾是誰？
- 畫出來的圖到底是產品圖功能圖還是技術圖又或是大雜燴？
- 圖上的框框有點少是不是要找點兒框框加進來？
- 佈局怎麼畫都不滿意……
如果有同樣的困惑，本文將介紹一種畫圖的方法論，來讓架構圖更清晰。
先理清一些基礎概念
1、什麼是架構？
架構就是對系統中的實體以及實體之間的關係所進行的抽象描述，是一系列的決策。
架構是結構和願景。
系統架構是概念的體現，是對物/信息的功能與形式元素之間的對應情況所做的分配，是對元素之間的關係以及元素同周邊環境之間的關係所做的定義。
做好架構是個複雜的任務，也是個很大的話題，本篇就不做深入了。有了架構之後，就需要讓干係人理解、遵循相關決策。
2、什麼是架構圖？
系統架構圖是為了抽象地表示軟件系統的整體輪廓和各個組件之間的相互關係和約束邊界，以及軟件系統的物理部署和軟件系統的演進方向的整體視圖。
3、架構圖的作用
一圖勝千言。要讓干係人理解、遵循架構決策，就需要把架構信息傳遞出去。架構圖就是一個很好的載體。那麼，畫架構圖是為了：
- 解決溝通障礙
- 達成共識
- 減少歧義
4、架構圖分類
蒐集了很多資料，分類有很多，有一種比較流行的是4+1視圖，分別為場景視圖、邏輯視圖、物理視圖、處理流程視圖和開發視圖。
場景視圖
場景視圖用於描述系統的參與者與功能用例間的關係，反映系統的最終需求和交互設計，通常由用例圖表示。
邏輯視圖
邏輯視圖用於描述系統軟件功能拆解後的組件關係，組件約束和邊界，反映系統整體組成與系統如何構建的過程，通常由UML的組件圖和類圖來表示。
物理視圖
物理視圖用於描述系統軟件到物理硬件的映射關係，反映出系統的組件是如何部署到一組可計算機器節點上，用於指導軟件系統的部署實施過程。
處理流程視圖
處理流程視圖用於描述系統軟件組件之間的通信時序，數據的輸入輸出，反映系統的功能流程與數據流程,通常由時序圖和流程圖表示。
開發視圖
開發視圖用於描述系統的模塊劃分和組成，以及細化到內部包的組成設計，服務於開發人員，反映系統開發實施過程。
以上 5 種架構視圖從不同角度表示一個軟件系統的不同特徵，組合到一起作為架構藍圖描述系統架構。
怎樣的架構圖是好的架構圖
上面的分類是前人的經驗總結，圖也是從網上摘來的，那麼這些圖畫的好不好呢？是不是我們要依葫蘆畫瓢去畫這樣一些圖？
先不去管這些圖好不好，我們通過對這些圖的分類以及作用，思考了一下，總結下來，我們認為，在畫出一個好的架構圖之前， 首先應該要明確其受眾，再想清楚要給他們傳遞什麼信息 ，所以，不要為了畫一個物理視圖去畫物理視圖，為了畫一個邏輯視圖去畫邏輯視圖，而應該根據受眾的不同，傳遞的信息的不同，用圖準確地表達出來，最後的圖可能就是在這樣一些分類裡。那麼，畫出的圖好不好的一個直接標準就是：受眾有沒有準確接收到想傳遞的信息。
明確這兩點之後，從受眾角度來說，一個好的架構圖是不需要解釋的，它應該是自描述的，並且要具備一致性和足夠的準確性，能夠與代碼相呼應。
感覺寫的不錯的，希望各位看官點贊轉發關注，謝謝
閱讀更多 程序猿愛code 的文章
