前言與經歷
建築行業有場地平面圖，軟體架構也需要一個簡單容易好理解的圖形表達形式
在進行專案軟體開發的時候，常常遇到必須要跟其他工程師溝通的狀況，同時也要明確的整理規劃自己的架構思路邏輯，一開始我在進行圖像繪製的時候，都是使用draw.io 憑理解而這個製圖工具進行架構圖畫圖，但是每當我畫完以後，即便我覺得很明確了，但是還是要跟人解釋整體圖像模型架構，而假如再看其他工程師的架構圖的時候，更是痛苦，根本完全看不懂，需要當事人做一次整體架構的基底說明，所以我就找到了一套目前通用且廣受好評的軟體系統建模圖形表示技巧 C4Model，並帶領組員同事共同使用這個架構模型，減少彼此之間的架構溝通的阻礙。透過這樣的建模圖形表示技巧讓懂程式的人看得懂，不懂程式的門外漢也看得懂!
簡介
C4模型是軟體系統建模的圖形表示技巧。同時市面上還有其他的工具、做法方式，比較知名的就是UML、ArchiMate 和 SysML，但是UML..這類本身過於複雜，說實話，9成的人看圖都只是看個大概而已，過於複雜的圖難以傳承以外，耗時又耗力，所以基本上大部分的狀況下是不需要過於複雜的圖形表示，可能只要線和盒子就好。故C4Model就是一個很好的呈現方式。
C4 Model
C4 Model為軟件開發團隊提供了一種方式，以不同的詳細程度，向不同類型的受眾講述不同的故事，從而有效地傳達他們的軟件架構記錄和現有的代碼庫。
架構圖的視野由高至低分為四個等級，第一等級是最上層也是最粗略的。
Level 1: 系統上下文圖(System Context diagram)
這個階層主要是將各種使用者/角色需要使用的功能畫出來，並不會有技術名詞或實作的相關做法，可以想像成User story的做法，將使用者的需求簡易的描述出來，跟哪些系統有關聯
範圍：單一軟件系統。
主要元素：範圍內的軟件系統。
支持元素：在範圍內直接連接到軟件系統的人員（例如用戶、參與者、角色或角色）和軟件系統（外部依賴項）。官網建議是把這次專案要開發的系統放在中間，以藍色的方塊來表示；灰色則是既有系統或非本專案需開發系統，再用虛線將系統界線畫出來。
目標受眾：軟件開發團隊內外的所有人，包括技術人員和非技術人員。
推薦給大多數團隊：是的。
Level 2: 容器圖(Container diagram)
放大系統後的容器可以是網頁應用程式、桌面應用程式、Ａpp、資料庫等。在容器圖內可以看到各個應用程式（模組）間的相互溝通
範圍：單一軟件系統。
主要元素：軟件系統範圍內的容器。
支持元素：直接連接到容器的人員和軟件系統。
目標受眾：軟件開發團隊內外的技術人員；包括軟件架構師、開發人員和運營/支持人員。
推薦給大多數團隊：是的。
注意：此圖沒有說明部署方案、集群、複製、故障轉移等。
Level 3: 元件圖(Component diagram)
第三階段的圖其實就是再放大Lv2的應用程式，將應用程式內容更深入地畫出每個元件。
範圍：單個容器。
主要元素：範圍內容器內的組件。
支持元素：容器（在範圍內的軟件系統內）加上直接連接到組件的人員和軟件系統。
目標受眾：軟件架構師和開發人員。
推薦給大多數團隊：不，僅當您認為它們增加了價值時才創建組件圖，並考慮為長期文檔自動創建它們。
Level 4: 程式(Code)
第四層用在特別的決策圖即可，可以表示什麼樣的條件該走什麼路。
範圍：單個組件。
主要元素：範圍內組件內的代碼元素（例如類、接口、對象、函數、數據庫表等）。
目標受眾：軟件架構師和開發人員。
推薦給大多數團隊：不，只要儲存在長期文檔，大多數IDE可以按需求生成。
補充圖
系統景觀圖(System Landscape diagram)
整個企業用到的所有軟體系統概覽。
範圍：企業。
主要元素：範圍內與企業相關的人員和軟件系統。
目標受眾：軟件開發團隊內部和外部的技術人員和非技術人員。
動態圖(Dynamic diagram)
主要傳達某些特別動態訊息傳遞方式之類的表示方式。
範圍：企業、軟件系統或容器。
主要和支持元素：取決於圖表範圍；企業（參見系統景觀圖）、軟件系統（參見系統上下文或容器圖）、容器（參見組件圖）。
目標受眾：軟件開發團隊內部和外部的技術人員和非技術人員。
部署圖(Deployment diagram)
多個系統互相影響下，部屬相關。
範圍：一個或多個軟件系統。
主要元素：部署節點、軟件系統實例和容器實例。
支持元素：軟件系統部署中使用的基礎設施節點。
目標受眾：軟件開發團隊內外的技術人員；包括軟件架構師、開發人員、基礎架構架構師和運營/支持人員。
符號相關的建議(準則)
圖表
- 每個圖都應該有一個描述圖類型和範圍的標題（例如“我的軟件系統的系統上下文圖”）。
- 每個圖表都應該對於所使用的符號圖例（例如形狀、顏色、邊框樣式、線型、箭頭等）有一個解釋。
- 首字母縮寫詞和縮寫詞（業務/領域或技術）應為所有受眾能夠理解的，或是能夠在圖表鍵/圖例中進行解釋的。
元素(元件)
- 每個元素的類型都應該明確指定（例如人員、軟件系統、容器或組件）。
- 每個元素都應該有一個簡短的描述，以提供關鍵職責的“概覽”視圖。
- 每個容器和組件都應該有明確指定的技術。
關係(線)
- 每條線都應該代表一個單向關係。
- 每條線都應該有標籤，標籤與關係的方向和意圖一致（例如依賴關係或數據流）。嘗試盡可能具體地使用標籤，最好避免使用諸如“使用”之類的單個詞。
- 容器之間的關係（通常這些代表進程間通信）應該具有明確標記的技術/協議。
參考或引用資料：
軟體架構之Ｃ4模型：https://myctw.github.io/post/d11.html
工程師畫圖 | 看懂C4 Model | 比UML更好懂的系統架構圖：https://youtu.be/rr9OUCC6h2M
