1. 程式人生 > 其它 >怎麼畫出好的架構圖,架構師必備。。

怎麼畫出好的架構圖,架構師必備。。

作者:程式碼的色彩
連結:https://juejin.cn/post/7062662600437268493

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官網,然後加上了一些筆者的理解。

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

3.2.1 語境圖(System Context Diagram)

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

3.2.2 容器圖(Container Diagram)

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

3.2.3 元件圖(Component Diagram)

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

4.怎麼畫好架構圖

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

4.1 檢視的受眾

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

4.2 檢視的元素區分

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

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

近期熱文推薦:

1.1,000+ 道 Java面試題及答案整理(2022最新版)

2.勁爆!Java 協程要來了。。。

3.Spring Boot 2.x 教程,太全了!

4.別再寫滿屏的爆爆爆炸類了,試試裝飾器模式,這才是優雅的方式!!

5.《Java開發手冊(嵩山版)》最新發布,速速下載!

覺得不錯,別忘了隨手點贊+轉發哦!