軟體系統架構設計的目标不在于設計本身，而在于架構設計意圖的傳達。圖形化有助于在團隊間進行高效的資訊同步，但不同的圖形化方式需要語義一緻性和效率間實作平衡。C4模型通過不同的抽象層級來表達系統的靜态結構，并提供了最小集的抽象模組化元素，為設計人員提供了一種低認知負載、易于學習和使用的高效模組化方式。
1 為什麼要進行架構可視化？
軟體系統架構設計的目标不在于設計本身，而在于架構設計意圖的傳達。如果不能清晰、一緻的在幹系人間進行設計意圖的同步，即使再好的設計也隻是空中樓閣。軟體架構設計本質上也是一種抽象和模組化的過程（對模型和抽象的本質參考文章《 領域驅動設計開篇 》），軟體架構設計模型的表達有多種方式：圖形化、語言和文字。絕大部分場景下，圖形化在架構設計的表現力層面效果更佳。是以，對于軟體系統架構進行可視化表達是有價值，且是必要的。
軟體架構可視化的方式有多種，不同的團隊有不同的實踐方式，最為常見的由如下幾種：
• 線框圖：通過線框圖和連線表達架構元素及之間的關系
• UML：統一模組化語言，表達系統的靜态結構和動态行為
• 草圖：非正式的圖形
不同的可視化方式各有優劣，以下部分将對不同的表現形式進行說明
1.1 可視化方式-線框圖
線框圖是最為通用的可視化表達方式之一，架構師或設計人員大量的架構圖，比如技術架構、功能架構、資料架構、邏輯架構等等都通過線框圖的形式表達。該種可視化方式的優勢是：
• 模組化工具多樣化：你可以基于Viso、Drawio、PPT等任何一款支援線框圖的軟體進行模組化工作
• 學習成本低：設計人員幾乎不需要進行專門的模組化語言以及模組化工具的學習，門檻較低
但，基于線框圖表達軟體系統架構存在的問題也非常明顯：語義的一緻性問題
你可能自己畫過很多軟體系統架構圖，也可能參與評審過其他團隊的架構圖，我相信，對你而言并不是的所有的圖都是“清晰且易于了解的”。舉個簡單的場景，如果我們在百度搜尋 “架構圖” ，你可能得到以下結果：
各式各樣的 “架構圖”：不同形狀和顔色的圖形元素、不同形狀和顔色的連線、不同的意圖。
我們可以看出：線框圖雖然簡單，但其其圖形化的語義一緻性是大問題。雖然都是通過線框表達軟體系統架構，但不同的人可能使用不同的元素、不同的顔色、不同的連線和分層等等，線框自由表達的靈活性和圖形化語義的一緻性存在潛在沖突，最終都會阻礙架構設計意圖傳達。
1.2 可視化方式-UML
UML是統一模組化語言，相比于線框圖而言，其優勢是在軟體模組化層面提供了一緻性的模組化元語言。簡單來說，UML提供了大家達成一緻的（UML支援擴充的場景除外）模組化元素。如果團隊成員比較熟悉UML，那麼通過UML表達的系統架構圖天然具有認知一緻性。
豐富靈活的模組化元語言在提升語義一緻性的同時，也必然會導緻複雜性的上升。掌握UML具有一定的學習成本，而熟練的應用對研發人員也提出了更高的要求。基于 Simon Brown給出的資料，實際情況隻有少數團隊真正使用UML。不論是UML的複雜度和學習成本原因，還是靈活化下對UML的排斥，很多團隊都放棄了UML。
我們不能否認UML的價值，基于統一模組化語言能夠更有效的進行架構設計的資訊傳遞和溝通，也能基于UML提供的詳細的模型圖元素進行充分的設計表達。團隊中是否要基于UML進行溝通需要權衡，雖然UML不能表達你所要傳達的全部的架構資訊，但其在某些次元的表達相對比較适合。
• 表達流程和工作流可以采用UML活動圖
• 表達運作時的互動可以采用UML時序圖
• 表達領域模型或者設計模式可以采用UML類圖
• 表達狀态轉換可以采用UML狀态機
• 表達系統的部署結構可以使用UML部署圖
1.3 可視化方式-草圖
架構可視化另一個非常常見的方式是：草圖。草圖是一種非正式的、易于快速溝通的圖形化方式。團隊基于特定的場景，可以通過草圖的形式進行快速的溝通，以便高效的在幹系人間拉齊關鍵資訊。
但，草圖的劣勢與線框圖一樣：語義一緻性低
我們可以在白闆上 “随心所欲” 的畫各式各樣的草圖，草圖上的元素、連線，又或者布局都可能是湧現式的、臨時性的，這些草圖的價值在于 “會話周期内的高效溝通”。如果幹系人沒有完全參與到草圖的讨論，又或是後置檢視，大概也很難精準捕獲這些草圖所要表達的設計意圖。
2 C4 模型
2.1 C4模型的統一抽象
團隊需要統一語言進行高效溝通 !!!
C4模型在不同的級别提供了統一的抽象以表達軟體系統的靜态結構。如下圖所示：
• 軟體系統：最頂層的抽象，其對使用者提供價值。包含待建構的系統以及外部依賴的系統
• 容器：表示一個應用或者資料存儲，容器需要運作以支援系統的正常運轉。每個容器都是獨立部署或運作的單元，容器間的通信一般式跨程序互動
• 元件：提供一定能力封裝的單元。在C4模型上下文中，元件不是獨立部署的單元，一般情況下運作于容器之中。
• 代碼：系統的實作細節相關
• 人：系統的使用使用者
2.2 上下文圖：System Context Diagram
我們要建構的系統不會孤立存在，都會依賴現有的IT設施。要明确我們建構的系統是什麼，宏觀上需要回答：我們的系統如何融入到現有的IT設施。
系統上下文圖正是從高層視角表述待建構系統與目前IT設施的互動及邊界。通過上下文圖：
• 展示與軟體系統互動的各方及互相關系
• 展示軟體系統與外部環境的邊界
• 作為了解系統架構的切入點
• 確定所有人都了解、認可系統的工作範圍
2.3 容器圖：Container Diargram
更進一步的剖析核心系統，回答：系統由哪些容器組成？容器的職責是什麼？以及相關的高層的技術選型是什麼？
與Docker的容器概念不同，C4模型的容器是在 “系統” 作用域之下，其表達的是組成系統的可獨立可部署的實體單元。以下圖為例：單個容器元素重包含了名稱、職責描述、技術選型，同時，容器間的連線及标注辨別了其高層的互動協定及互動形式。
2.4 元件圖：Component Diagram
進一步的剖析容器，回答：容器由哪些元件組成？這些元件的職責及元件間的互動形式是什麼？
具體到每個容器内部，通過多個元件及元件間的關系表達容器的組成。“元件” 本身是一個泛化的概念，C4模型的元件是在 “容器” 的作用域之下，其表現形式可能是獨立的Jar包，或者是應用内獨立的包，也可能是類級别，但邏輯上都能夠表達一個元件的概念。對于元件圖關鍵的是要表示清楚元件的實作選型、元件職責以及元件間的互動關系。
2.5 代碼
代碼處于C4模型的最低層，且是可選的，其關注的是實作相關。C4模型并沒有對實作層面的可視化進行統一抽象，開發人員可以選擇UML類圖、E-R圖等進行可視化。是否需要提現代碼層面研發人員基于具體情況具體分析，一般情況下，如果系統中需要重點關注的部分可以考慮一些代碼級别的圖支援，比如，我們非常關注系統設計的可擴充性，則關鍵部分可能需要一些類圖表達；又或者非常關注底層資料模型，則E-R圖可以納入考慮範圍。
3 C4模型實踐中的決策和問題
連線表達依賴關系還是資料流向 ？
都可以，C4模型中的連線既可以表達依賴方向，也可以表達資料流向。原則上，設計人員需要保證其清晰且無歧義。實踐中一般通過合理的文字說明來明确的表達元素間的關系。
Jar或類庫應該模組化為“容器”？ “元件” ？
Jar包或類庫一般是連結到調用方的程序中，作為程序中的一部分存在，這種依賴一般不表示為容器，而是元件。當然，是否要将Jar，比如SDK表示為元件并展現在元件圖上需要設計人員具體情況具體分析。
資料存儲系統應該模組化為 “軟體系統” 還是 “容器” ？
資料存儲系統，比如MySQL、DFS等一般是作為獨立的外部存儲叢集存在，叢集的運維可能歸屬于公司的運維團隊。以OSS為例，但從應用角度而言，即使叢集的運維不歸屬目前開發團隊，團隊也會申請租戶隔離的專屬空間，是以，在C4模型中這種情況應該表述為 “容器”。
消息系統應該如何模組化 ？
消息系統一般作為兩個容器間的互動媒介，是以在C4模型中消息系統的模組化存在兩種方式：
• 依賴消息系統的容器都顯示與消息系統互動，明确的表達各自與消息系統的依賴關系或資料流向
• 屏蔽消息系統，隻提現容器間的依賴關系，并對依賴進行明确說明
圖形化的過期問題
C4模型本身也是一種文檔化機制，同樣也存在過期問題。隻不過C4模型通過對系統在不同的層級進行抽象，每個抽象層級的過期頻率不同，由上到下逐漸增大，上下文圖的變化頻率最小，而代碼級則變化最大。
為什麼C4不涉及業務流、狀态機、資料模型等模組化
C4模型僅對系統的靜态結構進行模組化，并不試圖囊括或替代其它模組化方式，C4模型并不适合所有次元的可視化表達。對于業務流可以基于BPML、UML活動圖進行表達，狀态機可以基于UML狀态機圖進行表達，而資料模型可以通過E-R圖表達，不同模組化語言互相補充。
4 系統架構設計關注不同次元
作為架構師或系統設計人員，在進行系統架構設計時一般會關注不同次元，一般情況下，對于業務系統建設而言，會關注以下次元。在架構設計（架構和設計）過程中，基于C4模型、UML及BPML等多種模組化方式互相補充，不同表現次元下可以采用不同的模組化方式
• 業務流程：泳道圖或UML活動圖，表達核心的業務流
• 業務用例、系統用例：UML用例圖
• 領域模型：UML類圖
• 系統邊界：C1，系統上下文圖
• 高層技術選型：C2，容器圖
• 系統職責配置設定：用線框圖表示功能架構
• 關鍵部分的實作：C3，元件圖
• 系統關鍵的互動邏輯：UML時序圖
• 資料模型：E-R圖
• 關鍵實體的狀态機：UML狀态機圖
• 不同的高優先級架構屬性的設計：比如，緩存方案、幂等性設計方案、定時任務補償政策、降級限流政策等等，這些都與具體的需求所關注的高優先級的架構屬性相關。