概念地圖・C4 架構四層
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：創新
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
C4 架構四層：一層一個讀者，畫到看得完為止
承辦第一次被問到「你們系統長什麼樣」，他從抽屜抽出一張 A3。圖上四十七個方塊，箭頭穿來穿去，問的人看了七秒就把視線移開。C4 把這件事拆成四張圖——系統脈絡、容器、元件、程式碼——由外向內一層一層放大，每一層只留這個尺度該有的方塊與箭頭，上一層畫過的東西，下一層不重畫。它看起來像製圖規範，用起來卻是一套「這次不畫什麼」的紀律。
四層縮放，一層一個讀者
先看一件事：每一層都有自己的收件人，換一層就換一個人。
| 層 | 這一層回答什麼 | 框數 | 誰在看 |
|---|---|---|---|
| 第 1 層 系統脈絡 | 我們這套系統跟外面誰有往來 | 5 個（中心 1 ＋ 外圍 4） | 局長與跨機關窗口 |
| 第 2 層 容器 | 系統內部由哪幾塊可以各自部署的東西組成 | 4 個 | 維運廠商 |
| 第 3 層 元件 | 其中一塊容器裡面怎麼分工 | 4 個（只拆一塊） | 接手的工程師 |
| 第 4 層 程式碼 | 這個元件的類別長什麼樣 | 不畫 | IDE 與編譯器 |
最右邊那一欄才是這套框架真正的軸。第一層畫給要簽字的人看，他只需要知道往來對象有誰、責任在哪裡斷開；第二層畫給半夜會被電話叫醒的人看，他要知道哪一塊掛了會發生什麼事。到第四層，收件人已經換成機器——IDE 會替你展開類別關係，編譯器會替你檢查有沒有對上，人再手畫一次只是在做重工。表上那個「框數」不必當成配額，它的用處是提醒：這一格如果塞到十幾個框，代表你把兩層的東西畫在同一張紙上了。
每一層該不該畫，看四個問題
一、這一層有沒有自己的收件人。C4 的四層是四種放大倍率，倍率之所以成立，是因為每一級都有人真的需要那個尺度。畫之前先確定這張圖會被誰打開、他打開之後要做什麼決定；找不到那個人，這一層就是畫給自己看的。自問：這張圖畫完，我要拿去給誰看，他看完要決定什麼？
二、框的尺度是不是同一級。同一張圖裡出現「戶役政資訊系統」和「寄信用的那支函式」，讀者的腦袋會當場失焦——他無從判斷哪個大、哪個小、哪個歸誰管。尺度混雜是四層圖最常見的破口，比框太多更傷。自問：這張圖裡最大的框和最小的框，能不能用同一句話介紹？
三、往下只准拆一個。第三層的意義在於「挑一塊」，而挑本身就是判斷：你認為風險、複雜度或爭議集中在那一塊。四塊全拆等於沒挑，圖會在兩次會議之內長回四十七個方塊。自問：我為什麼挑這一塊往下拆，另外三塊為什麼可以先當黑盒？
四、停在哪一層。停手的判準要去讀者那邊找。多畫一個框，如果沒有人的決定會因此改變，那個框就是裝飾。C4 之所以把第四層留在規格書上而現實中幾乎沒人畫，理由正是這條。自問：再多畫一個框，誰的行動會跟著改？
一間戶政事務所的預約系統，四層縮一次
把那張四十七個方塊的 A3 收起來，同一套臨櫃預約系統，重畫一次。
- 第 1 層 系統脈絡：中間放「臨櫃預約系統」，外圍只留四個——民眾、臨櫃承辦、內政部戶役政資訊系統、簡訊發送商。五個框，一頁講完。局長要的答案全在這一張
- 第 2 層 容器：把中間那一格打開，裡面是四塊可以各自部署、各自掛掉的東西：預約網站、臨櫃叫號機、預約資料庫、夜間批次介接程式。維運廠商第一次知道半夜該盯哪一塊
- 第 3 層 元件：只拆預約網站，畫出身分驗證、時段查詢、通知發送、稽核紀錄；叫號機、資料庫、批次程式維持黑盒。想把四塊一起拆開的那一刻，圖就開始長回原來的樣子
- 第 4 層 程式碼：不畫。會後總有人說「這樣不夠完整」——完整是對誰而言，這句話沒說
四層縮完，任何一張圖都沒超過六個框，而那張 A3 上的四十七個方塊一個都沒消失，它們只是被分配到不同的紙上，各自去找自己的讀者。真正的收穫發生在第三層那個選擇：承辦挑了預約網站往下拆，等於當眾承認「我認為麻煩集中在這裡」。這句話寫在圖上比寫在會議紀錄裡更難賴掉，也更容易被人反駁——而被反駁正是畫圖的價值。跨機關那條線也一樣：第一層上它是一條箭頭，會議上卻是唯一有人願意花時間吵的東西。圖幫不了你談成，圖只是讓要談的那件事終於有個位置可以指。以上為說明結構用的示意情境，僅供理解框架之用。
這套四層圖什麼時候會騙你
- 層數被當成進度條。「我們畫到第三層了」聽起來像進度，實際上說的是你挑了一塊往下看。四層不是成熟度分級，畫到第四層也不代表這套架構被想清楚了——第四層的收件人是編譯器，它從來不會因為你畫了圖而少報一個錯。真正該追蹤的進度是：這四張圖各自送到收件人手上了嗎，他們看完各自做了什麼決定。
- 第二層悄悄長回第一層。最常見的破法是把第一層那四個外部角色整組搬進第二層，理由總是「這樣比較完整」。結果一張圖同時服務兩種收件人，維運廠商要在跨機關的箭頭裡找他那台主機，局長要在四塊容器裡認出他關心的那條線，兩邊都得多花力氣。每往內一層只保留該尺度的東西，這條規矩的成本永遠是「有人覺得少畫了」。
- 四個框被讀成清單全貌。圖上那四塊容器是取捨過的結果，讀者卻很容易把它當成清點過的名冊。現實裡有十一塊要維護的東西，硬壓成四個框，圖會很漂亮，值班表會很痛苦。碰到這種情況，正確的動作是承認這一層裝不下：把同層拆成兩張圖，或往上退一格重畫。把第十一塊塞進某個框的角落用小字標一行，只會讓值班的人在最需要它的時候找不到它。
痛點視角下的四層縮放
畫得深，常常只是不敢刪。
一張圖一路畫到第四層，通常跟讀者的需要無關，跟畫的人願不願意當眾說出「這一層我們不畫」比較有關。少畫要負責，多畫不必——於是圖愈長愈滿，滿到沒有人看得完，也就沒有人能挑戰它。這張圖畫得出系統的邊界與內部分工，畫不出哪一條線上有人在痛：預約網站與戶役政系統之間，圖上是一條乾淨的箭頭，現場可能是承辦每天早上把同一組身分證字號重打一次。P.A.I.N. 那把尺問的是誰在痛、痛多深、值不值得有人掏錢解決；四層縮放回答的是誰跟誰有連線、責任在哪裡斷。兩件事都需要，但只有前者能決定你該把工程時間放在哪一條箭頭上。今晚可以做一件小事：把最近一次要拿去給人看的架構圖打開，先在紙上寫下它會送到誰桌上、那個人看完是要點頭還是要動手，然後回頭刪框，刪到他七秒之內看得完為止。
常見問題
四層一定要全部畫完嗎？
不必，而且多數團隊只畫前兩層。C4 的原始說明本來就把第四層當成選配，理由很實際：類別圖從程式碼自動生成的品質，比手畫的更新更快也更準。第三層則看情況，通常只在某一塊容器複雜到需要交接、或即將換人維護時才畫，而且一次只拆一塊。把「畫完四層」當成交付標準，多半會生出三張沒有人打開的圖。
C4 說的「容器」跟 Docker 容器是同一件事嗎？
兩件事只是共用了一個詞，而這個詞正是這套框架最容易卡住經理人的地方。C4 的容器指的是「可以獨立部署、也可以獨立掛掉」的一塊東西：一個網站、一支手機 App、一個資料庫、一支排程程式，都算一個容器；它跟用什麼技術打包無關。判準很單純——這塊東西能不能自己重啟、自己故障，而其他部分還活著。能，它就是一個容器；不能，它比較可能是下一層的元件。
C4 跟事件風暴差在哪，兩個都要做嗎？
兩者看的東西不同。事件風暴是一群人圍著牆，把業務上「已經發生的事」按時間順序貼出來，找的是流程裡的斷點與歸屬爭議；C4 沒有時間軸，它畫的是同一套系統在四種放大倍率下的靜態長相。實務上常見的順序是先用事件風暴把業務講清楚，再用 C4 把落地的邊界畫下來。要不要兩個都做，看你現在卡在哪一邊：說不清誰做了什麼，先貼牆；說不清誰跟誰有連線，先畫圖。
一張圖最多幾個框才合理？
沒有官方數字，但有個好用的土法：一張圖如果沒辦法在七秒內讓收件人指出「跟我有關的是哪一格」，它就太滿了。經驗上第一層維持在七個框以內、其他層維持在十個以內，多數會議都撐得住。超過的時候，先問是不是尺度混雜了；尺度沒問題還是太多，就把同一層拆成兩張圖，各自標明這一張要回答什麼。
畫圖的人最容易忘記，圖是給人看的。想把同一套系統換成時間軸來看、找出流程斷在哪一步，下一站是事件風暴；想釐清哪一層該由誰負責、誰來覆核，可以接著讀三道防線模型。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。