系統架構圖是什麼？常見類型、C4模型與看懂的方法

作者｜瞻新資訊　張安邦執行長（台大醫工背景・十年以上IT服務公司創辦人）

拿到一份系統架構圖，卻看不懂上面那些方塊跟箭頭在講什麼——這是很多非技術背景的主管、老闆在跟開發團隊溝通時常遇到的狀況。系統架構圖不是畫給工程師自己爽的技術文件，而是讓不同角色（老闆、PM、工程師、維運）能站在同一個理解基礎上溝通系統長什麼樣子的工具。

這篇文章把系統架構圖講清楚：常見的類型有哪些、現代業界常用的C4模型怎麼分層、常見的架構模式（單體、分層、微服務）差在哪，以及怎麼看懂一份架構圖。

系統架構圖是什麼？為什麼不能省略這一步

系統架構圖是用視覺化的方式，呈現一個系統由哪些部分組成、這些部分之間怎麼互動與依賴的圖表。它的價值不在於畫得多精美，而在於能不能讓不同角色快速對齊理解：老闆看得懂系統大致的樣貌與邊界、PM看得懂各模組之間的關係好規劃時程、工程師看得懂實作細節、維運人員看得懂系統部署在哪裡、怎麼串接。

跳過架構圖直接動手開發，常見的後果是團隊各自對系統的理解不一致，等到開發到一半才發現彼此想的不是同一回事，這時候要修正的成本遠比一開始花時間對齊架構圖高得多。

系統架構圖的常見類型

「系統架構圖」其實是一個統稱，實務上依照要呈現的內容不同，會用到不同的圖表類型：

• 系統架構圖／脈絡圖：呈現系統的整體樣貌、邊界，以及跟外部系統、使用者的互動關係，通常給較不熟悉技術細節的關係人看
• UML圖：統一塑模語言，是一套標準化的塑模符號，涵蓋結構圖形（類別圖、元件圖、部署圖等）與行為圖形（使用案例圖、活動圖、狀態機圖等），較常用在工程團隊內部的技術溝通
• 資料流程圖（Data Flow Diagram）：專門描述資料在系統裡怎麼流動、怎麼進出系統、資料儲存在哪裡，適合釐清資料處理邏輯
• 網路拓撲圖：呈現系統的實體或虛擬網路部署方式，例如主機、伺服器、防火牆之間怎麼連接，較常用在維運與資安情境

不同類型的圖表解決的問題不一樣，實務上一個系統開發專案常常會需要用到不只一種圖表，各自對應不同的溝通對象。

C4模型：現代系統架構圖的分層畫法

近年業界越來越常見的做法，是用「C4模型」來畫系統架構圖。這套方法由Simon Brown在2006到2011年間提出，設計初衷是取代UML這類相對笨重的建模方式，用更簡單、更有彈性的方式記錄系統架構。

C4模型的核心概念是像地圖一樣，分成四個由粗到細的層級：

1. System Context（系統脈絡圖）：最頂層的圖，畫出整個系統的邊界、有哪些使用者會用到這個系統、系統跟外部有哪些其他系統互動。這一層是給完全不懂技術細節的關係人看的，重點是「這個系統跟誰有關係」
2. Container（容器圖）：把系統脈絡圖放大，畫出系統內部的物理結構——每一個「容器」代表一個可以獨立執行或部署的單元，例如網站前端、後端API、資料庫。這一層開始有技術含量，適合PM與工程團隊溝通
3. Component（元件圖）：再放大，畫出某個容器內部由哪些元件組成，通常是工程團隊內部討論設計時使用
4. Code（程式碼圖）：最細的層級，畫出元件內部的程式碼結構，這一層通常由開發工具自動產生，很少需要手動維護

C4模型的一個特色是不強制使用特定的圖形符號或建模語言，方框加箭頭就能表達，門檻低、彈性高，這也是它近年在業界推廣度越來越高的原因之一。

常見的系統架構模式：單體、分層、微服務

畫架構圖時，系統本身採用的架構模式也會直接影響圖要怎麼畫。常見的架構模式有：

架構模式	核心概念	主要優點	主要限制
單體式（Monolithic）	介面、商業邏輯、資料存取全部開發成單一應用程式	開發初期簡單、部署單純	系統變大後難以維護，牽一髮動全身
分層式（Layered）	依職責分層（展示層、商業邏輯層、資料層），上層只依賴下一層	職責分工清楚，容易理解	通常整體仍是單體部署，無法獨立部署單一功能
微服務（Microservices）	拆解成多個獨立、可各自部署的服務	擴展性好、故障隔離、團隊可各自開發	架構複雜度高，需要額外的服務間溝通與維運機制

這裡有個常被搞混的地方：單體式vs微服務講的是「應用程式怎麼被拆分部署」，分層架構講的則是「應用程式內部怎麼分工」，這是兩個不同維度的架構決策，不是互斥的對立選項——一個單體式應用程式內部可以是分層架構，一個微服務裡的每個服務內部也可以各自採用分層架構。

看懂架構圖的幾個關鍵符號

多數系統架構圖雖然沒有統一的畫法規範，但常見的視覺慣例大致相通：方框通常代表一個系統、服務或元件；箭頭代表資料流向或呼叫依賴關係，箭頭的方向通常表示「誰呼叫誰」或「資料往哪裡流動」；圓柱形通常用來表示資料庫；虛線框有時用來表示系統的邊界（例如公司內部網路跟外部網路的分界）。看架構圖時，先抓大方向——這張圖是給誰看的（決定它該是C4模型的哪一層）、箭頭在表達依賴還是資料流動，通常就能抓到七八成的重點，不需要每個符號都完全理解才能看懂圖要傳達的意思。

常見的架構圖繪製工具

實務上團隊常用專門的圖表協作工具畫架構圖，例如draw.io、Lucidchart這類工具，能用拖拉方框與箭頭的方式快速產出圖表，也方便團隊共同編輯與版本管理。工具本身的選擇不是重點，重要的是團隊能不能持續維護這份圖，讓它保持跟實際系統同步——一份過時的架構圖，有時候比沒有架構圖更容易誤導人。

系統架構圖什麼時候該畫？誰該看

架構圖不是只有開發階段才需要：專案提案階段，用C4模型的系統脈絡圖層級，能幫助客戶快速理解這個系統大致的樣貌與邊界，不需要陷入技術細節；進入開發階段後，容器圖與元件圖能幫助工程團隊對齊設計，避免各自理解不一致；系統上線之後，維運人員也需要參考架構圖（搭配網路拓撲圖）了解系統實際部署在哪裡、出問題時該往哪裡排查。同一份系統，在不同階段、給不同人看，適合呈現的細節層級並不一樣，這也是為什麼C4模型「由粗到細分層」的設計思路特別實用。

動手畫系統架構圖之前，先想清楚這幾件事

要畫一份系統架構圖，建議先想清楚：這張圖主要是給誰看（決定該用哪一層級的細節）、系統本身打算採用什麼架構模式（單體、分層、微服務，或是混合）、以及圖表用途是溝通提案，還是要作為工程團隊長期維護的技術文件。想清楚這些，畫出來的架構圖才能真正發揮讓不同角色對齊理解的作用，而不是變成一份沒人看得懂、也沒人願意維護的過時文件。

系統架構圖看似只是一張圖，但背後反映的是整個系統的設計決策，也是團隊溝通、日後維運的重要基礎。如果還在評估該找哪個團隊協助規劃系統架構，可以參考系統整合商這篇文章。瞻新資訊在協助客戶做系統開發時，會依專案階段規劃合適層級的架構文件，有需要的話歡迎聊聊你的專案需求。

FAQ