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 模型 架構視圖，可以讓團隊內的人，從不同層面上入手，快速到找到自己關注的要點，這是非常有利於團隊內對系統設計的溝通的。
參考資料：