架構製圖：工具與方法論

作者 | 楚衡

前言

“架構製圖” 這詞乍一聽似乎有些晦澀，但如果提起 “工程製圖”，相信絕大部分工科背景的程序員們都不會陌生，甚至還能共同感慨下那些年一起伏在宿舍左手圓規，右手直尺，徒手作圖到深夜的日子。

軟件工程也是工程，因此傳統工程製圖的一些基本理論，在軟件行業同樣適用。但另一方面，軟件與實體制造業之間還是有着本質區別，所以在製圖方面的需求和方式也大相徑庭，無法直接套用。作爲軟件行業的從業者，你可以完全不懂工程製圖，但你不得不懂架構製圖 —— 這是任何程序員職業生涯的的必修課。

本文在後半段將介紹如何用圖去描述（describe）和傳達（communicate）你的架構設計。值得強調的是，本文並不會側重於單一的方法和工具，而是更希望關注那些優秀方法背後的通用方法論，即架構製圖的本質、共性和最佳實踐。希望本文能起到引子作用，激發大家對自己日常工作中關於架構和製圖部分的關注、審視與思考；如果還真能幫助大家提升一點點製圖效率和效果，那就更好不過了。

什麼是軟件架構？

1. 軟件架構定義

================

IEEE 給出的定義：架構是環境中該系統的一組基礎概念（concepts）和屬性（properties），具體表現就是它的元素（elements）、關係（relationships），以及設計與演進的基本原則（principles）。

CMU 軟件工程研究院的定義：架構是用於推演出該系統的一組結構（structures），具體是由軟件元素（elements）、元素之間的關係（relationships），以及各自的 ** 屬性（properties）** 共同組成。

Uncle Bob 在 Clean Architecture 一書中給出的定義：架構是創建者給予該系統的形態（shape）。這個形態的具體形式來源於對系統組件（components）的劃分和排列，以及這些組件之間互相通訊的方式。

2. 架構核心要素

綜合上述各種權威定義，軟件系統的架構通常需要包含如下四類核心要素：

爲什麼架構很重要？

1. 架構是系統實現的藍圖

====================

最近有部很火的網劇叫《摩天大樓》，講述了一段匪夷所思的懸疑故事。爲什麼扯這個呢？因爲我想借用這個劇的標題來問個問題：摩天大樓是由誰建起來的？也許你心裏會默唸：廢話，不就是建築工人們一磚一瓦堆起來的嘛。仔細再想想？背後是不是還有一堆操碎了心的建築設計師（比如劇中帥氣的林大森）和土木工程師們？他們雖然不搬磚也不扛水泥，但如果沒有他們產出的那些繁瑣嚴謹的設計圖紙，摩天大樓是是不可能像農村自建房一樣僅憑工人們各自的經驗與想象力就能快速平穩地豎立起來的。

正是靠着這些圖紙所描繪出來的工程藍圖（blueprints），才讓成百上千工人們的分工合作和驗收標準有了依據：大家只需要照着藍圖，按部就班地把自己所負責的那些磚瓦添上去就行了；只要藍圖正確，且施工過程也沒有偏差，最終順利完工只是個時間問題。

與建築、汽車或者任何其他工程行業一樣，軟件在落地實現（編碼）之前也需要先有藍圖；而其中最重要的一份藍圖，就是架構設計。沒有架構，僅憑程序員自己腦子裏的模糊設想，也許你可以像傳統手藝人一樣獨自創造出一些美好有用的小東西（比如 Linux 0.01 版本），但不太可能以工程的方式協同一個團隊共同建造起一個與摩天大樓規模類似的複雜軟件系統（比如現代的 Linux 系統）。一方面，人類的思維能力終歸有限，必須依靠架構這種高度抽象和簡化的藍圖，才能讓複雜系統的創造、理解、分析和治理變得可行；另一方面，量級達到一定程度的大型系統，也只能依靠多人分工合作才能完成，而架構也正是多人溝通協作的重要基礎。

2. 架構是溝通協作的基礎

 

軟件項目的最終價值產出就是軟件系統，而架構作爲軟件系統的靈魂和骨架，可以起到如下作用：

3. 架構決定了產品質量

如何衡量一個軟件產品的質量？上圖是 ISO/IEC 25010 標準定義的軟件產品質量模型，包括以下 8 個大類：

上述質量模型中列出的所有點，都是架構設計需要着重考慮的。其中除了功能適合性以外，其他所有點都屬於非功能需求的範疇，這也是區分架構好壞的真正分水嶺 —— 好的架構設計，不會停留在僅滿足功能需求這一最基本的需求層次上（最壞的架構設計也同樣能做到），更重要且更難以應對的是其他衆多的非功能需求。

當然，魚與熊掌不可兼得。架構與人生一樣，也是一場權衡的遊戲，弄不好就跟第八季的龍母一樣的下場：既要又要還要，最後反而什麼都得不到。好的架構師更應該像雪諾同志學習，表面上 “know nothing”，實際上 “know everthing”：清楚系統所有利益相關者（stakeholders），努力挖掘各方的主要述求（concerns），相應平衡自己的架構決策（decisions），最終實現你好我好大家好的終極架構目標。

4. 我還能說出更多理由

要不是篇幅所限，這一頁 PPT 顯然不夠裝：

如何設計一個好的架構？

理解了架構的概念和重要性後，真正的架構師修煉之路纔剛剛開始。如何設計一個好的架構？這顯然是一個非常博大精深的主題，但並不是本文的重點，因此這裏只簡單列舉了一些基本思想（原則）和經典套路（模式）。當然，架構設計更接近一門經驗學科，僅停留在能脫口而出一些玄乎而高大上的理論概念肯定是不夠的，需要結合實際工作內容和業務場景多多實踐和揣摩纔行，否則只能算是徘徊在架構的門外，連入門都談不。

1. 架構原則（principles）

SOLID 原則是一套比較經典且流行的架構原則（主要還是名字起得好）：

此外，我們做架構設計時也會盡量遵循如下一些原則（與上述 SOLID 原則在本質上也是相通的）：

2. 架構模式（patterns）

架構模式（architectural patterns）與我們常討論的設計模式（design patterns）並不是一碼事，但如果僅從 “模式” 這個角度去解讀，兩者的理念都是一致的：針對給定上下文中經常出現的問題的通用、可複用的解決方案。最主要的區別在於，架構模式會更高維抽象和偏全局整體（畢竟是運用在架構設計層面）。

常見的架構模式，既包括一些傳統模式（e.g. 分層、C/S、MVC、事件驅動），也包括一些新興玩法（e.g. 雲原生、微服務、Serverless）。不同模式有不同的適用場景，沒有哪一種模式能通殺所有需求。成熟的架構師應該像一個冷靜到冒得感情的殺手，永遠只會客觀地評估和選擇最適合當下的解決手段，即使那麼做會顯得簡單乏味；相反，不成熟的架構師，一心總想着搞事情（e.g. 強行套用微服務架構），而不是真正搞定問題。

怎麼描述你的架構設計？

有了良好的架構設計，萬里長征之路就已經走了一大半。就像是青年導演第一次遇上好劇本，心潮澎湃兩眼放光，彷彿已經預見了電影上映後的票房盛況。當然，剩下的一小半路，並不會如想象中那麼平坦 —— 同樣的劇本，不同導演拍出來會有質一樣的區別。好的 “最佳導演”，即使面對不是“最佳劇本” 的劇本，也有能力拍出“最佳影片”。同樣，好的架構師，也應該有能力描述好一個不錯的架構設計；即使做不到爲精彩的內容加分，也不應該因爲形式上沒描述好而丟分，否則就會像高考作文丟了卷面分一樣憋屈和心酸。

1. 架構描述的意義

爲什麼要描述架構？讓它只存在我深深的腦海裏不行嗎？西方人有句諺語：好記性不如爛筆頭。任何沒有持久化的東西都是易失的（volatile），就跟內存一樣。另一方面，就如前文所述，架構是溝通協作的基礎，不通過架構描述（Architecture Description）沉澱下來讓所有項目干係人都能看到，那就失去了溝通和傳播的唯一載體。

根據個人觀察，大家對 “架構需要描述” 這一點都沒異議，所以絕大部分項目都或多或少會產出一些有模有樣的架構描述文檔。但 “有架構描述” 和“有好的架構描述”，這之間的鴻溝是巨大的，甚至比 “沒有” 和“有”之間的差別還大。如果你也跟我一樣，飽經滄桑閱盡無數架構文檔，曾拍手叫好心懷感激過，也曾拍着大腿憤怒不已過，應該也能感同身受。

2. 架構描述的方式

對於同一件事物，作家會選擇用文字來敘述，而畫家卻會用圖畫。儘管兩者想要傳達的信息是一致的，但描述方式的不同也會帶來效果上的巨大差異。架構描述也分 ** 文字（Text）和圖（Diagram）** 兩種形式，兩者各有千秋：

聰明的你冷笑了一聲：哼，又不是小孩子非得做選擇題，難道不可以文字與圖都要嗎？當然可以，理想的架構描述一定是圖文並茂的。但現實世界顯然比理想殘酷，實際軟件項目中很難給你留足時間先憋出一篇完美的架構文檔。如果以成年人的思維去考慮投入產出比（ROI），那麼你一定會優先選擇畫圖。

3. 爲什麼你應該優先畫圖？

敏捷軟件開發宣言中提到：相比詳盡的文檔，可運作的軟件更加重要（Working software over comprehensive documentation）。這麼說當然不代表就不用寫文檔了，只是提倡沒必要寫過於詳盡的文檔。爲什麼？因爲詳盡的文檔需要耗費大量的編寫和維護成本，不符合敏捷開發的小步迭代和快速響應變化等原則。

那麼，在如今這個全面敏捷開發的時代，如何也順應潮流更加敏捷地編寫架構文檔呢？ROI is your friend —— 不求多，但求精，儘量用最少的筆墨表達出最核心的內容。從內容上來說，ROI 高的部分一般是偏頂層的整體架構或最核心的關鍵鏈路，這點在後文的 C4 模型理念中也有體現。而從形式上來說，圖在文字面前具有無與倫比的表達力優勢，顯然是 ROI 更高的選擇。

4. 爲什麼你需要學習畫圖？

多畫圖是沒錯，但有必要專門學習嗎？又不是素描彩筆水墨畫，只是畫一堆條條框框而已，稍微有點工程常識的都能上。畫的有點醜？那沒關係，頂多再動用點與生俱來的藝術美感，把這幾條線對對齊那幾個框擺擺正，再整點五彩斑斕的背景色啥的，不就顯得很專業了嘛？

看到這裏，屏幕前的你又輕蔑一笑：哼，顯然沒這麼簡單。確實，道理說出來大家都懂，架構製圖與工程製圖一樣，都是一件需要下功夫認真嚴謹對待的事情。但現實中大部分人還真沒這工夫去下那功夫，比如上面貼的兩幅很常見的架構圖。第一張圖不用多說，這種草圖自己塗塗抹抹挺好，但拿出來見人就是你的不對了。那第二張圖呢，看上去似乎還挺像那麼回事的？並不是，如果你更仔細地去揣摩，就能發現這張圖底下所隱藏的很多模糊和不嚴謹之處（可參考這張圖的來源文章：The Art of Crafting Architectural Diagrams）。

所以，能畫圖並不代表能畫好圖；要想製得一手既漂亮又可讀的好圖，還是需要經過持續學習與刻意練習的，很難僅憑直覺和悟性就能掌握其中的關鍵要領。此外，錯誤的圖往往比沒有圖還要糟糕，即使你只是抱着 “有圖就行，差不多那個意思得了” 的心態，也至少應該理解一些科學制圖的關鍵要素，避免給本來就已經很複雜難做的項目又蒙上一層模糊濾鏡，甚至起到混淆和誤導的反作用。

5. 架構製圖的目標

討論具體的製圖方法和工具前，我們需要先豎立清晰的製圖目標。工具是人類進化的階梯，但如果理解和利用不當，則很容易反過來被工具所限制甚至奴役，忘了最初發明和使用工具的初心。對於架構製圖而言，已經有那麼多形形色色的方法與工具，使用它們的初心是什麼呢？我認爲本質上都是想把製圖這個過程從一門自由的手藝變成一項科學的工程：系統、嚴謹、完整、標準化，同時能做到可重複、可持續和高效。

P.S：當時做 PPT 太趕，所以從這個章節開始的配圖，只能被迫走極簡路線了，還請見諒。。。

架構製圖方法與工具

經過前面幾個章節的 “簡短” 鋪墊，相信大家對架構製圖的背景知識都已經產生了足夠的認知。本章節將會具體列舉和描述一些典型的架構製圖方法與工具，其中有常見的也有罕見的，重點是希望能通過各種方法的橫向對比，加深大家對製圖方法本質的理解。

1. 方法一：UML

UML 應該是大部分人最熟悉的製圖方法了，最新的 UML 2.x 版本由以下兩大類圖組成：

作爲通用的 “統一建模語言”，UML 總共包含了 14 種不同類型的圖，可以全面覆蓋軟件設計領域各種製圖需求，當然也包括了架構製圖。同時，也正是因爲 UML 把自己當成了一門語言，因此其各種記號（notion）和語義（sematics）都有非常嚴謹的定義，不會出現模糊或者歧義問題。最後，UML 經過幾十年的發展和推廣，也早已成爲世界範圍內廣泛使用的標準規範，其所帶來的的隱性價值就是：在團隊內使用 UML 進行溝通的成本是比較低的，因爲可以假定絕大部分技術人員都能理解 UML 的含義和用法。

然而，UML 也非萬能（雖然歷史上曾一度把它當成軟件設計的銀彈），它最被人詬病的缺點就是過於複雜。這也不能怪 UML，畢竟它就是要被設計爲足夠通用、嚴謹和強大的，這些目標都與 “簡單” 背道而馳，並讓它一步步演化到了今天這個複雜刻板的龐然大物模樣。雖然上面我們自信地假定了技術人員大多都懂 UML，但這個 “懂” 如果帶上一個程度量詞，我覺得平均能到 20% 就不錯了 —— 絕大部分也就能認識幾個常見的類圖、時序圖，估計都很難準確說出類圖中各種箭頭的含義。

無論怎麼說，UML 依然應該是每個程序員的製圖工具箱中最常用和必備的工具之一。當然，也不應該是唯一，因爲下面也還有些不能錯過的好東西。

2. 方法二：4+1 View Model

“4+1”是啥？不知道沒關係，聽過 “6+1” 嗎？對，就是那個小時候常看的 “非常 6+1” 節目。它跟 “4+1” 之間的關係，就跟它們與邵佳一、張嘉譯和沈佳宜之間的關係一樣，除了趕巧共用了同一個後綴發音以外，八竿子打不着。

所以，“4+1” 到底是指什麼？讓我們來 Wiki 一下：“4+1” 是一種視圖模型（view model），可以通過多種共存的視圖描述軟件密集型系統的架構。這些視圖基於不同項目干係人（利益相關者）的視點（viewpoint），例如：終端用戶、開發者、系統工程師和項目經理。“4+1”由 4 種基礎視圖和一些經過挑選的用例或場景（即額外的 “+1” 視圖）組成，各自的具體含義如下：

雖然上面提到 “4+1” 的各種視圖一般都是用 UML 圖來表示，但實際上 “4+1” 本身是一種通用的視圖模型，並沒有限制繪圖的記號和工具。對於工程師而言，這種偏學院派的方法可能這輩子都不會直接用到，但其中蘊含的一個關鍵架構製圖思想非常有價值：架構需要通過多種視圖來描述，而這些視圖是來源於不同項目干係人的視點（角度）；只有這樣才能產生一整套全面、立體且客觀的架構描述。

3. 方法三：C4 Model

C4 模型是一種 “抽象優先”（abstraction-first）的架構製圖方法，它也是受前面的 UML 和 “4+1” 視圖模型所啓發，但相對而言要更加簡單和輕量，只包含少量的一組抽象和圖表，很易於學習和使用。

1）定義、理念與關鍵思想

C4 模型通過容器、組件、代碼以及人這幾個抽象來描述一個軟件系統的靜態結構，它的核心理念是希望像 Google Map 一樣，通過不同層次的細節，爲代碼建立一種可以放大和縮小的導覽圖。它最關鍵的思想就是自頂向下對系統的靜態結構進行逐級拆分，依次描述各層次對象的職責、關係和外部依賴。除了核心的層次化靜態結構視圖，它還可以包含動態視圖、部署視圖等補充視圖。

上面的左圖展示了 C4 模型中各層次抽象之間的映射關係：1 個軟件系統由 1~N 個容器組成，1 個容器由 1~N 個組件組成，1 個組件由 1~N 個代碼結構組成。右圖是以簡單的 Spring PetClinic 項目爲例，演示了一個真實軟件系統在 C4 模型下的層次結構：最上層就是 PetClinic 軟件系統，它可以拆分爲數據庫、Web 應用等幾個容器；Web 應用又可以進一步拆分出 ClinicService 這個組件，而這個組件下又包含了 ClinicService 接口類、ClinicServiceImple 實現類、Owner / Pet / Visit 等領域對象類。

使用 C4 模型進行架構製圖，本質上就是對上述幾種抽象進行可視化。具體的做法是依次建立如下幾類從粗到細的結構圖：Context、Container、Component 和 Code（可選），這也是 C4 模型名稱的來歷。

2）Level 1：System Context diagram

系統上下文圖作爲第一級（L1），提供了一個展示系統全貌的 ** 頂層大圖（big picture）** 視角，包括最中心的軟件系統、周邊的用戶以及其他有交互的系統。其中最關鍵的兩個概念分別是：

在繪製系統上下文圖時，不需要關心諸如技術棧、協議等任何底層細節。這類圖的受衆是最廣的，因爲任何人都可以理解並從中獲取到足夠的信息，包括技術人員和非技術人員，也包括團隊內成員和團隊外成員。

3）Level 2：Container diagram

通過 L1 的上下文圖理解了系統在整個 IT 環境中的定位後，下一步就是把系統這個框框放大，詳細看下其中包含了哪些 “容器”（Container，注意不要跟 Docker 容器搞混了噢！）。C4 模型中的容器是指單個應用或數據存儲，通常可以獨立部署和運行（有獨立的進程空間，通過 IPC 機制互相通訊），例如：SpringBoot 微服務、React SPA、移動 App、數據庫、Serverlss 函數、Shell 腳本。

L2 的容器圖不僅展示了系統的進一步職責拆分，還包括了主要的技術選型、容器之間的通訊方式等關鍵架構信息。這類圖可以面向全部的技術人員，既包括架構師、開發者，也包括運維人員、技術支持等。

4）Level 3：Component diagram

繼續前面的套路，下一步就是把系統中各個容器再分別進行局部放大，將每個容器進一步拆分成多個組件（Component）。在 C4 模型中，組件是指一組通過良好接口定義封裝在一起的相關功能（通常運行在同一個進程空間內），例如：Spring 裏的一個 Controller（不只包括定義了 REST 接口的 Controller 主類，也包括背後所有相關聯的實現類，如 Service/Repository 等）。

與容器圖類似，L3 的組件圖也不只包含了容器的組件劃分，還包括各個組件的職責定義、技術與實現細節等。隨着層次的下沉和細節的增多，組件圖的受衆範圍進一步縮窄，一般只適用於軟件架構師和開發者（其他角色沒必要理解，一般也理解不了）。

5）Level 4：Code（可選）

再繼續對組件進行放大，所能看到的最底層和細節的信息，就是 L4 的代碼（Code）了。當然，這裏所謂的 “代碼” 還是以圖的形式（e.g. UML 類圖、數據庫 E/R 圖）展示類或文件粒度的代碼結構，並不是真正的代碼本身。即便如此，代碼圖在 99% 的架構描述場景下也依然過於詳盡，一方面數量龐大，繪製成本很高；另一方面易於變化，維護成本也非常高。因此，一般只有非常重要和複雜的組件才需要用到這一層級進行描述。如果確實需要繪製，也應該優先考慮自動化的方式，比如很多 IDE 就支持自動生成 UML 類圖。

6）補充圖：Landscape / Dynamic / Deployment Diagram

除了上述各個層次的靜態結構圖，C4 模型還提出了一系列的補充圖（Supplementary diagrams），包括：

結合了這些補充圖後的 C4 模型，纔是可以全面與立體地描述出軟件架構方方面面的完全體架構製圖方法。

4. 方法四：arc42

嚴格來說，arc42 並不是一種架構製圖方法，而是一個架構文檔模板。雖然如前文所說，在架構描述中 “圖” 是比 “文字” 更高優的選擇，但實際項目過程中你終究還是需要產出一份相對完整、有圖有文字的架構文檔。arc42 就是專門用於幫助大家更好地編寫架構文檔；而作爲架構文檔中最重要的架構圖，顯然 arc42 也不會放過 —— 其中多個核心章節都與架構圖有關，且詳細描述了相應的製圖方法。這裏不會詳細展開介紹 arc42（不能搶了下一篇文章的飯碗），只會簡單介紹下 arc42 中製圖方法與 C4 模型的異同。

偉大的思想都是相似的，arc42 也不例外。上方左圖的右側部分，概括了 arc42 模板中與製圖相關的幾個核心章節，分別是：

因此，本質上 arc42 中提倡的製圖方法與 C4 模型是等價和兼容的，完全可以配合使用：以 arc42 作爲架構文檔框架，其中的架構製圖採用更具體的 C4 模型。這也是目前我們項目中實際採用的方法。

5. 其他方法 & 製圖工具

除了上述幾種方法以外，在軟件行業蓬勃發展的數十年間也湧現出過很多其他的優秀架構製圖方法，其中既包括一些通用方法，如：SysML、AADL、ArchiMate，也包括一些領域特定方法，比如在企業中後臺業務建模場景中很常見的 BPMN。再詳細地展開描述各個方法，顯然會讓本文又臭又長（雖然寫到這裏時似乎就已經註定了），有興趣的讀者可以自行檢索和探索。

到這裏爲止，本章節介紹的都是架構製圖的各種方法；而實際從方法到落地的過程中，還有一個繞不開的環節：選用什麼樣的工具去製圖？總不能真的跟寫工程製圖作業一樣用紙和筆吧？作爲數字化改革的推動者，程序員們當然要全面擁抱數字化工具；大家日常工作中必然也已經積累了很多順手的畫圖工具，因此這裏我只推薦兩個自己用得比較多的：

架構製圖方法論總結

古有云：授人以魚，不如授人以漁。推而廣之：授人以方法，也不如授人以方法論。什麼是方法論？雖然這個詞在公司裏已經用爛了，但確實有它的價值和意義：方法論（methodology）是對方法的更高維度抽象，由它可以推導出解決問題的具體方法（method）。理解了方法論，才能融會貫通，掌握解決問題的本質要點；你也不會再受限於單一的具體方法，因爲使用任何方法都能快速上手和靈活運用，並得到差不多的同等效果。

因此，本文最後這一章節將對各種架構製圖方法進行歸納總結，並嘗試提煉出一個通用的架構製圖方法論，期望能幫助大家更好地理解架構製圖背後的原理和思想。即便現在所熟知的各種方法與工具終會過時，也依然能風輕雲淡地看待它們的新老交替：** 過去是 UML，現在是 C4，未來是什麼呢？這並不關鍵，** 因爲即使方法過時了，背後的方法論也不會過時。

所以，那些茫茫多的方法背後，究竟是什麼樣的核心方法論在支撐着呢？經過作者嘔心瀝血冥思苦想了近 15 秒鐘，終於總結出瞭如下這套經典方法論（p.s：就是湊數的，不要太當真~ ）。由於其中包含了 5 個環環相扣的要點，我們姑且稱它爲：五環理論。

1. 理解制圖目標

架構製圖的第一要點，是需要先深刻理解制圖目標。正所謂 “以始爲終”，有了目標我們才能清晰地前行；否則漫無目的地亂竄，往往會多走不少彎路，甚至南轅北轍。架構製圖的目標是什麼？其實前文已經提到過很多，這裏再簡單總結下：

2. 找準受衆和關注點

架構製圖的第二要點，是要找準你製圖的受衆（audience）以及他們各自的關注點（concern）。找不準的話，要麼效果大打折扣（不是他們想聽的），要麼猶如對牛彈琴（他們根本就聽不懂）。常見的一些受衆和關注點可包括：

3. 自頂向下逐層描述

架構製圖的第三要點，是合理運用層次化（hierarchical）的套路，自頂向下逐層描述。無論是 C4 模型還是 arc42 模板，背後都深刻運用並顯著強調了這一點。爲什麼一定要這麼做？其中蘊含了兩個普適的原理：

4. 使用多種架構視圖

架構製圖的第四要點，是在向傳統的工程製圖方法論致敬：使用多種架構視圖來描述你的架構。在工程製圖的世界裏，任何立體的製品，大到機牀小到零件，都至少需要通過三種視圖（主視圖、俯視圖、左視圖）來描述。作爲現實世界的映射，軟件系統也是多維和立體的，只用單一視圖不可能覆蓋所有關鍵的架構信息；即使強行把這些信息都塞在一張圖裏，那也一定會複雜到讓人無法理解。

在架構設計領域，架構視圖（architectural view）有專門的定義：針對系統架構某一個方面（aspect）的一種描述；每個視圖都會覆蓋項目干係人的一種或多種關注點。從上述定義可以看出來，不同的架構視圖會有不同的側重點，同時在描述自己所專注的方面時也會略去與當前視圖無關的其他細節 —— 這其實也是一種與層次化拆分類似的分而治之思想，只不過這裏是針對完整系統的維度分解，而層次化則是針對某一具體視圖再做自頂向下的垂直下鑽（drill-down）；兩者是正交且可以相互配合的，例如前面說到的結構視圖、部署視圖甚至動態視圖，都可以分別再進行層次化拆分。

5. 遵循規範和最佳實踐

架構製圖的第五要點，其實只是一句正確的廢話：遵循規範和最佳實踐。這一點已經不限於架構製圖，而是上升到了工程實踐領域的通用方法論層面。正如前面章節所說，“學習架構製圖的目標，就是要把它從一門手藝變成一項工程”，因此架構製圖的 “施工” 過程也理所應當符合工程化思維：

附：架構描述標準化概念模型

國際上對架構描述其實建立了專門的標準（ISO  / IEC / IEEE 42010:2011），其中的很多概念詞彙在本文中都有提到（e.g. Stakeholder、Concern、View、Viewpoint），有興趣的同學可以進一步研究下。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/oRrZIBLwjCRJG3xJcm5bdA

猜你喜歡