hi，我是熵減，見字如面。

對於軟體開發團隊來說，寫軟體設計檔案，花架構圖，是日常工作中的關鍵一項。

而其中，如何畫好系統設計的架構圖呢？ Simon Brown 就提出 C4 模型，來解決這個問題。

基於C4模型的腳手架，架構師們就可以統一團隊內的不同層級的視角，交付一個成體系的架構設計。

下面具體看一下C4模型吧。

什麼是C4模型？

C4 模型是一種輕量級的軟體架構圖的表示法，旨在幫助團隊更好地理解和溝通軟體架構設計。

C4代表了四個層次的抽象化，即：

上下文（Context）：上下文層次主要描述了軟體系統與外部系統或人員之間的互動關係，其目的是為了提供軟體系統的背景和整體結構。
容器（Container）：容器層次描述了軟體系統中的容器（如伺服器、資料庫等）以及它們之間的關係，其目的是為了提供軟體系統內部的大體結構。
元件（Component）：元件層次描述了容器內的元件（如Web應用程式、服務、資料庫架構等）以及它們之間的關係，其目的是為了更細緻地瞭解軟體系統的內部組成。
程式碼（Code）：程式碼層次描述了元件內的程式碼實現，其目的是為了幫助開發者更好地瞭解元件的實現和技術細節。

如上圖所示，這四個層次對應著從高到低的不同的抽象程度。對應到軟體系統中來說，就是能夠從不同的層級檢視上，展示軟體的架構，使得設計者和開發者們可以更好地理解、交流架構設計，並推進架構的演進升級。

第1級:系統上下文圖

系統上下文圖是軟體系統設計的起點，是讓你後退一步以看到大的視角。

畫一個圖表，將你的系統顯示為中心的一個盒子，周圍是展現的主要是兩類資訊：

本系統的使用者是誰；
本系統如那些外部系統有互動。

細節在這裡並不重要，因為這是你縮小的檢視，顯示了系統全景的大圖。重點應該放在人(參與者、角色、角色等)和軟體系統上，而不是技術、協定和其他低階細節上。這是一種可以展示給非技術人員的圖表。

呈現範圍：單個軟體系統。
主要元素：範圍內的軟體系統。
支援元素：在範圍內直接連線到軟體系統的人員(例如使用者、參與者、角色或角色)和軟體系統(外部依賴項)。通常，這些其他軟體系統位於您自己的軟體系統的範圍或邊界之外，您對它們沒有責任或所有權。
目標受眾：每個人，包括技術人員和非技術人員，軟體開發團隊內外的人員。
注意：推薦推薦給大多數團隊。

第2級：容器圖

此處的容器，不是指Docker的一個容器。

而是類似於伺服器端web應用程式、單頁應用程式、桌面應用程式、移動應用程式、資料庫模式、檔案系統等。

本質上，容器是一個單獨的可執行/可部署單元(例如，一個單獨的程序空間)，用於執行程式碼或儲存資料。

系統上下文圖將本系統看作一個黑盒，那麼容器圖則是把這個黑盒開啟，深入到了軟體的內部，展示了軟體內體系結構的高階形狀，以及職責如何在其中分佈。

它還展示了主要的技術選擇以及容器之間如何通訊。

這是一個簡單的、以技術為重點的高階圖表，對軟體開發人員和支援/操作人員都很有用。

呈現範圍：單個軟體系統。
主要元素：範圍內軟體系統中的容器。
支援元素：直接連線到容器的人員和軟體系統。
目標受眾：軟體開發團隊內外的技術人員;包括軟體架構師、開發人員和操作/支援人員。
注意：推薦推薦給大多數團隊，該圖沒有說明部署場景、叢集、複製、故障轉移等。

第3級：元件圖

元件圖，則是進一步放大並分解了每一個容器，

接下來，您可以放大並進一步分解每個容器，以識別容器內的主要結構構建塊，及其互相之間的互動關係。

元件圖展示了容器是如何由許多「元件」組成的，每個元件是什麼，它們的職責和技術/實現細節等。

呈現範圍：單個容器。
主要元素：範圍內容器中的元件。
支援元素：容器(在軟體系統範圍內)加上直接連線到元件的人員和軟體系統。
目標受眾：軟體架構師和開發人員。
注意：不推薦給大多數團隊，如果你覺得元件圖增加了價值，那麼只建立元件圖，並考慮為長期存在的檔案自動化建立元件圖。

第4級：程式碼結構圖

如果需要深入到元件程式碼層面，程式碼結構圖可以顯示元件是如何作為程式碼來實現的。主要是使用使用UML類圖、實體關係圖或類似的方法。

理想情況下，這種底層細節的圖表，將使用工具(例如IDE或UML建模工具)自動生成，應該考慮只顯示那些，你想要重點關注的屬性和方法。

所以，除了最重要或最複雜的元件之外，不建議使用這種詳細級別。

呈現範圍：單個元件。
主要元素：元件作用域中的程式碼元素(例如類、介面、物件、函數、資料庫表等)。
目標受眾：軟體架構師和開發人員。
注意：不推薦用於大多數團隊，對於長期存在的檔案，大多數IDE工具都可以按需生成這種級別的詳細資訊。

使用C4模型的6個注意點

在團隊架構中，使用C4模型來呈現架構檢視時，需要注意以下幾點：

目標清晰：在繪製C4模型之前，應該明確需要建模的系統、軟體或架構的目標。確保每個層次上的圖表都有明確的目的，能夠傳達給觀眾或其他利益相關者有關係統或軟體的資訊。
約定識別符號：在繪製C4模型時，應使用一致的識別符號來命名和標識不同的元素，例如系統、容器、元件和程式碼等。這有助於提高模型的可讀性和理解性。
簡單明瞭：C4模型強調簡潔、清晰的表述。在繪製C4模型時，應避免使用過多的細節或技術語言，以確保每個層次上的圖表都易於理解。
易於更新：C4模型應該能夠隨著時間的推移而更新，以反映系統或軟體架構的演變。在繪製C4模型時，應該考慮如何使其易於維護和更新。
適度細節：在繪製C4模型時，應考慮到每個層次上需要展示多少細節。如果圖表過於複雜，可能會導致人們難以理解和使用。
迭代性：C4模型是一個迭代的過程。在實踐中，您可能需要多次繪製和修改C4模型以滿足需求，並使其更好地反映系統或軟體架構。

總之，C4模型是一種簡單但強大的建模方法，可以幫助您建立清晰、易於理解和易於維護的軟體架構圖表。通過遵循上述建議，您可以更好地使用C4模型來設計和描述複雜的軟體系統。

實踐中常見的6個誤區

在使用C4模型時，可能會遇到一些常見的誤區。

以下是一些常見的誤區，以及如何避免這些問題的方法：

過度關注細節：C4模型旨在提供一個高層次的概述，以幫助人們理解系統或軟體架構。因此，過度關注細節可能會使模型過於複雜，難以理解。建議在模型的每個層次上保持適度的細節，以便讀者可以輕鬆理解。
忽略系統間的互動：C4模型強調系統的上下文檢視，但有時候人們可能會忽略系統之間的互動。在建模時，應該考慮系統之間的互動以及它們如何在軟體架構中發揮作用。
忽略時間和演變：C4模型應該是可演化的，這意味著模型應該能夠反映軟體架構的演變。在建模時，應該考慮如何使模型易於更新和維護，以便反映軟體架構的演變。
與UML混淆：雖然C4模型和UML有些相似之處，但它們是不同的建模方法。C4模型的重點是軟體架構，而UML的重點是物件導向的程式設計。因此，建議不要將C4模型與UML混淆。
未充分考慮受眾：C4模型的目的是使軟體架構易於理解。因此，在繪製模型時，應該考慮模型的受眾群體，併為他們提供足夠的上下文資訊和詳細說明。
忽略安全和效能：在建模軟體架構時，應該考慮安全和效能方面的因素。這些因素對系統的設計和實現都有重要影響，因此應該在C4模型中考慮它們。

總之，避免這些常見的誤區，可以在你的軟體架構建模工作中，讓C4模型更好的發揮作用。

寫在最後

C4模型的架構設計的腳手架，值得推薦的關鍵：就是其為架構設計圖，提供了一個分層的清晰的結構規範。

一份視覺化的 C4 模型架構檢視，可以讓團隊內的人，從不同層面上入手，快速到找到自己關注的要點，這是非常有利於團隊內對系統設計的溝通的。

參考資料：

C4模型，架構設計圖的腳手架，你值得擁有