你知道如何畫好一幅架構圖麼？

用一分鐘時間，你能在腦海裏構造一幅你最熟悉的系統的架構圖麼？先別往下看，本身先想象下。

混亂的架構圖

不知道你想象中的軟件架構圖是怎樣的，但我猜測你們畫的應該跟百度或者谷歌搜索「架構圖」出現的結果同樣：五花八門、形狀各異。

致使這個現象的緣由，我的認爲有如下幾點：

• 軟件架構的定義在大多數人內心不夠清晰
• 軟件架構是多維的，難以用簡單某個維度描繪全景
• 不一樣角色對於一個系統的關注點不同，所以其指望的軟件架構圖就會不同
• 對於軟件架構圖這個領域缺乏一個全軟件行業通用的「領域通用語言」，致使不一樣公司/人對 同一個名詞的理解各有差別

本文將試圖從以上幾個緣由出發，理清架構圖與架構的關係，讓你們能畫出與場景、角色相符的架構圖。

何謂軟件架構

要畫架構圖，那麼咱們首先須要清楚架構是什麼東西。

維基百科中，其說明軟件架構描繪的是：

• 構建構件及軟件系統的高層規則
• 軟件系統高層構件相互協做關係

軟件系統中的「架構」一詞引伸來源於建築學中的「架構」，架構是一個軟件系統的藍圖，其將會爲後續的詳細設計團隊指明設計方向,也會爲不一樣的系統相關方提供一個快速瞭解系統設計的途徑。

所以架構也是一個系統的根基、骨架，其在整個軟件系統生命週期中是詳細設計的基礎，若要改動則會傷筋動骨。

所以在架構設計時對各類構件的選型應綜合考慮各方面的訴求，適當選擇tradeoff,避免架構成爲整個系統的瓶頸。

軟件架構的維度

咱們對一個軟件系統有不少維度的要求，例如：

• 功能性需求
• 系統容錯性(fault-tolerance)
• 向後兼容性(backward compatibility)
• 可擴展性(extensibility)
• 可靠性(reliability)
• 可維護性(maintainability)
• 可用性(availability)
• 安全性(security)
• 易用性(usability)
• ......

不一樣的角色，對一個軟件系統架構所關注的角度也不一樣，例如：

• 用戶關注的是其功能實現、易用性及可靠性
• DDD的模型設計者關注的是各個領域模型之間的關係
• 開發者關注的是使用的開發技術棧、開發是否簡單
• 運維關注的是安全性、可用性、系統容錯性、物理部署等
• 系統全部者可能關心的是系統的可擴展性、可維護性

咱們從上面能夠看到，開發設計一個軟件系統須要綜合多個維度的考量，然而咱們所看見的圖僅是一個二維的表示，正所謂橫當作嶺側成峯，是沒有辦法把如此多維的信息一次過展示出來的。

所以須要完整地描述一個系統的架構必然須要從不一樣的維度出發，正交分解出某個維度的關注點，並將其在二維的圖中將其展現出來。

當各個維度都描述完成，在讀者人腦中，對這些二維數據進行組裝後，這個系統的立體形態就會被完整地呈現出來。固然不一樣人關注點也不同，可能也不必每一個人都熟悉一個系統的全部視圖。

回到標題所描述「畫一個你最熟悉系統的架構圖」時，咱們能夠知道，這個問題可能並不太嚴謹，由於架構是多維的，一幅架構圖只能從某一個維度去描繪架構。固然，這問題也有正確解，就是你從多個維度分別畫出多個架構圖。

軟件架構的視圖

正如上所說，軟件架構是多維的，受限於人類的思考能力及展現工具，咱們只能選擇從某個視圖（角度/維度）去看一個系統，由於看一個系統的維度不少，所以不一樣公司在內部誕生了不少不一樣的名詞：

• 技術架構
• 邏輯架構
• 物理架構
• 系統架構
• 應用架構
• 開發架構
• 運行架構
• 數據架構
• ......

不知道你們看暈了沒有，反正我是看暈了。以上的各類架構的名詞在不一樣的公司會有不一樣的含義，例如邏輯架構一詞，有的公司指代的是從業務邏輯維度看的架構（DDD的模型等），有的公司可能則指代一些中間件之間的主要協做與交互。

實際上一個名詞在不一樣公司有不一樣含義是很正常的事情，這取決於我的背景、或者更具體的——各個公司領導有沒有對某個名詞原有的含義產生誤解（或者說名詞自身就含有歧義）。

所以你們與人交流時，沒必要糾結於名詞自身，更沒必要因名詞定義而對某樣事情否認，咱們在交流過程當中應該尋找名詞背後的邏輯。

4+1視圖

上面的各類名詞混亂固然不是一個好的現象，咱們固然最好能構建一個「統一通用語言」，而4+1架構視圖是一個相對流行的架構視圖劃分方法。

4+1：

• 邏輯視圖
• 開發視圖
• 物理視圖
• 運行視圖
• 業務場景視圖
  

邏輯視圖

邏輯視圖關注的是提供給最終用戶的功能，所以其描述的是各個功能相關構件之間的協做關係，主要面向用戶、業務人員、開發組織。

其主要從系統的功能元素、以及它們的接口、職責、交互維度入手。主要元素包括系統、子系統、功能模塊、子功能模塊、接口等。

如UML中的類圖、DDD中的模型，微服務中的各個服務間協做關係 等都屬於邏輯視圖的範疇。

開發視圖

開發視圖從程序員角度去描繪架構，主要關注各種軟件包之間的協做關係，其不只僅包含本身寫的包，還包括應用程序依賴的SDK、第三方類庫、中間件等。

在DDD/MDD的理念中，在自行管理表徵業務邏輯的包/代碼將會和邏輯視圖的模型一一對應。

軟件分層圖、開發技術棧圖、應用與中間件協做視圖 等都屬於開發視圖的一部分。

物理視圖

物理視圖是從系統管理員的角度描繪系統的。其主要關注系統軟件組件在硬件層次的部署以及系統硬件之間相互協做關係。

物理視圖會包含具體的物理硬件及其部署的應用，如F5及其負載均衡、應用服務器及在上面運行的應用、各種中間件服務器及其上面運行的中間件還有網絡及IP等等元素

一個合理的物理架構設計，能支持通過合理設計的軟件系統實現 高可用、橫向擴展等特性

運行視圖

運行視圖側重於描述系統運行態，關注解釋系統在執行中的動做和組件如何溝通。

對於本視圖，我的瞭解不深，也沒法舉例說明。往各位大佬指點。

業務場景視圖

用部分關鍵業務場景來描述軟件系統自身。這些業務場景案例能夠用來走查架構設計中各個對象的協做關係，校驗總體架構設計的合理性，並做爲驗證架構原型可用性的測試案例。

其餘視圖

除了4+1視圖外還有一些額外的視圖：

• 數據視圖（數據持久化、副本策略等）
• 安全視圖

如何畫好一幅架構圖

再次回到標題，到如今，咱們知道，要畫好一幅架構圖，首先須要明確的是咱們要從多維的架構裏選擇哪一維做爲展現的重點。或者說，咱們要明確畫的這幅圖是給誰看的，其對這幅圖所關注點是什麼。

這樣咱們才能夠有的放矢，在其所關注的維度（邏輯、物理、運行、開發、數據等等）裏，選擇其關注的粒度（系統、服務、實例、接口等等）進行架構的描繪，才能得到特定閱讀者贊同，於是才能成爲一幅好的架構圖。

而對於一幅架構圖的關注點不明確/需求不明確時，咱們能給出的圖必然是模棱兩可，觸達不到痛點的。但願咱們能記住這一點，以此律己律人。

最後

本文是基於目前我的理解及多篇文章的參考而成，若本文對你有幫助，麻煩右下角點贊～，若文章有謬誤，望不吝批評斧正！

做者簡介：多年金融碼農，現爲某信用卡中心架構師，EasyTransaction做者，歡迎關注做者公衆號：

ref:

• https://en.wikipedia.org/wiki/Software_architecture
• https://en.wikipedia.org/wiki/4%2B1_architectural_view_model
• http://www.javashuo.com/article/p-xvbygjum-ep.html
• https://www.zhihu.com/question/27440059