畫一手好的架構圖是碼農進階的開始

1.前言

         你是否對大廠展示的五花八門,花花綠綠的架構設計圖所深深吸引,當我們想用幾張圖來介紹下業務系統,是不是對着畫布不知從何下手?作爲技術扛把子的筒子們是不是需要一張圖來描述系統,讓系統各個參與方都能看的明白?如果有這樣的困惑,本文將介紹一些畫圖的方法論,讓技術圖紙更加清晰。

2. 架構的定義

  • 系統架構是概念的體現,是對物/信息的功能與形式元素之間的對應情況所做的分配,是對元素之間的關係以及元素同周邊環境之間的關係所做的定義;
  • 架構就是對系統中的實體以及實體之間的關係所進行的抽象描述,是一系列的決策;
  • 架構是結構和願景.

       在TOGAF企業架構理論中, 架構是從公司戰略層面,自頂向下的細化的一部分,從戰略=> 業務架構=>應用/數據/技術架構,當然老闆層關注的是戰略與業務架構,我們搬磚的需要聚焦到應用/數據/技術架構這一層。

  • 業務架構: 由業務架構師負責,也可以稱爲業務領域專家、行業專家,業務架構屬於頂層設計,其對業務的定義和劃分會影響組織架構和技術架構;

  • 應用架構: 由應用架構師負責,需要根據業務場景需要,設計應用的層次結構,制定應用規範、定義接口和數據交互協議等。並儘量將應用的複雜度控制在一個可以接受的水平,從而在快速的支撐業務發展的同時,在保證系統的可用性和可維護性的同時,確保應用滿足非功能屬性的要求如性能、安全、穩定性等。

  • 技術架構: 描述了需要哪些服務;選擇哪些技術組件來實現技術服務;技術服務以及組件之間的交互關係;

  • 數據架構: 描述了數據模型、分佈、數據的流向、數據的生命週期、數據的管理等關係;

3.架構圖的分類

       系統架構圖是爲了抽象的表示軟件系統的整體輪廓和各個組件之間的相互關係和約束邊界,以及軟件系統的物理部署和軟件系統的演進方向的整體視圖。好的架構圖可以讓干係人理解、遵循架構決策,就需要把架構信息傳遞出去。那麼,畫架構圖是爲了:解決溝通障礙/達成共識/減少歧義。比較流行的是4+1視圖和C4視圖。

3.1 4+1視圖

3.1.1 場景視圖

        用於描述系統的參與者與功能用例間的關係,反映系統的最終需求和交互設計,通常由用例圖表示;

3.1.2 邏輯視圖

      用於描述系統軟件功能拆解後的組件關係,組件約束和邊界,反映系統整體組成與系統如何構建的過程,通常由UML的組件圖和類圖來表示。

3.1.3 物理視圖

         用於描述系統軟件到物理硬件的映射關係,反映出系統的組件是如何部署到一組可計算機器節點上,用於指導軟件系統的部署實施過程。

3.1.4 處理流程視圖

       用於描述系統軟件組件之間的通信時序,數據的輸入輸出,反映系統的功能流程與數據流程,通常由時序圖和流程圖表示。

3.1.5 開發視圖

        開發視圖用於描述系統的模塊劃分和組成,以及細化到內部包的組成設計,服務於開發人員,反映系統開發實施過程。

       5 種架構視圖從不同角度表示一個軟件系統的不同特徵,組合到一起作爲架構藍圖描述系統架構。

3.2 C4視圖

下面的案例來自C4官網,然後加上了一些筆者的理解。

image.png

        C4 模型使用容器(應用程序、數據存儲、微服務等)、組件和代碼來描述一個軟件系統的靜態結構。這幾種圖比較容易畫,也給出了畫圖要點,但最關鍵的是,我們認爲,它明確指出了每種圖可能的受衆以及意義。

3.2.1 語境圖(System Context Diagram)

      用於描述要我們要構建的系統是什麼,用戶是誰,需要如何融入已有的IT環境。這個圖的受衆可以是開發團隊的內部人員、外部的技術或非技術人員。

image.png

3.2.2 容器圖(Container Diagram)

       容器圖是把語境圖裏待建設的系統做了一個展開描述,主要受衆是團隊內部或外部的開發人員或運維人員,主要用來描述軟件系統的整體形態,體現了高層次的技術決策與選型,系統中的職責是如何分佈的,容器間是如何交互的。

image.png

3.2.3 組件圖(Component Diagram)

        組件圖是把某個容器進行展開,描述其內部的模塊,主要是給內部開發人員看的,怎麼去做代碼的組織和構建,描述了系統由哪些組件/服務組成,了組件之間的關係和依賴,爲軟件開發如何分解交付提供了框架。

image.png

4.怎麼畫好架構圖

       上面的分類是前人的經驗總結,圖也是從網上摘來的,那麼這些圖畫的好不好呢?是不是我們要依葫蘆畫瓢去畫這樣一些圖?先不去管這些圖好不好,我們通過對這些圖的分類以及作用,思考了一下,總結下來,我們認爲,明確這兩點之後,從受衆角度來說,一個好的架構圖是不需要解釋的,它應該是自描述的,並且要具備一致性和足夠的準確性,能夠與代碼相呼應。

4.1 視圖的受衆

        在畫出一個好的架構圖之前, 首先應該要明確其受衆,再想清楚要給他們傳遞什麼信息 ,所以,不要爲了畫一個物理視圖去畫物理視圖,爲了畫一個邏輯視圖去畫邏輯視圖,而應該根據受衆的不同,傳遞的信息的不同,用圖準確地表達出來,最後的圖可能就是在這樣一些分類裏。那麼,畫出的圖好不好的一個直接標準就是:受衆有沒有準確接收到想傳遞的信息。

4.2 視圖的元素區分

         可以看到架構視圖是由方框和線條等元素構成,要利用形狀、顏色、線條變化等區分元素的含義,避免混淆。架構是一項複雜的工作,只使用單個圖表來表示架構很容易造成莫名其妙的語義混亂。

 

讓我們一起畫出好的架構圖!

參考資料


作者:代碼的色彩
鏈接:https://juejin.cn/post/7062662600437268493
來源:稀土掘金
著作權歸作者所有。商業轉載請聯繫作者獲得授權,非商業轉載請註明出處。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章