好多年前，同事徐昊說過的一句話給了我很大啟發(fā)，他說“紙上的不是架構(gòu)，每個人腦子里的才是”。這句話告訴我們，即便是天天工作在一個團(tuán)隊里的人，對架構(gòu)的認(rèn)識也可能是不一樣的。每個人嘴上說的是類似的話，但心里想象的畫面仍然是不一樣的。在多年的工作中，我越來越認(rèn)可這句話所揭示出的道理。軟件開發(fā)是一個團(tuán)隊協(xié)作的工作，混亂的理解會造成架構(gòu)的無意義腐化、技術(shù)債的無意識積累、維護(hù)成本的無價值上升。

最近聽到一句話，“那些精妙的方案之所以落不了地，是因為沒有在設(shè)計上兼容人類的愚蠢”。話糙理不糙，雖然最終人們選擇的方案的思想都是在十年前甚至幾十年前就已經(jīng)存在的，然而在技術(shù)升級到足以“兼容”人類的愚蠢之前，這些思想只能在學(xué)術(shù)的故紙堆里睡大覺。當(dāng)然話糙確實也會有一個問題，將一個思想性問題轉(zhuǎn)化成了情緒性問題。人們?nèi)菀装岩恍┰阈牡氖虑闅w因到人類的愚蠢，在宣泄完不滿情緒后就停止思考了。作為知識工作者，我們的思維不能停步，我們需要思考到底人類有哪些愚蠢，分別用什么方法去避免或者“兼容”。

可以肯定彼此明明對自己開發(fā)的軟件有不一樣的認(rèn)識卻天天在一起討論問題并試圖把軟件做好是一件愚蠢的事情，為了兼容這種愚蠢我們需要采用可視化的方法。

為什么需要可視化呢，主要還是語言不靠譜。人類語言真的是太隨意了，只要你想，你可以說你見過一個方形的圓，并為此與別人辯論。但是無論如何你也畫不出來一個方形的圓，這就是我們需要可視化的原因。

今天我們介紹一個工具，叫做C4 model，這是我近幾年見到的一個比較難得跟我的認(rèn)知有大量共鳴的工具。

該工具的作者在多年的咨詢中經(jīng)常發(fā)現(xiàn)，很多個人畫出來的架構(gòu)圖都是不一樣的，但也不是說誰畫錯了，而是每個人的抽象層次不一樣。抽象層次這種東西，說起來好像存在，但真要說清楚還挺難，于是作者類比地圖，提出了縮放的概念。（兩年前我在教學(xué)生的時候提過同樣的概念）如下圖：

上面的四張地圖就是想說明，當(dāng)我們看待真實世界的“架構(gòu)圖”時候，也是要不停的縮放，在每一個層次刻意忽略一些細(xì)節(jié)才能表達(dá)好當(dāng)前抽象層次的信息。所以他類比著把架構(gòu)也提出了四個抽象層次：

從上到下依次是系統(tǒng)System、容器Container、組件Component和代碼Code。（咦，那為什么叫C4呢，因為系統(tǒng)的圖叫System Context，系統(tǒng)上下文圖。為了湊四個C也是夠拼的。）

基于這四個層次的抽象，C4模型由4張核心圖和3張附屬圖組成，分別用于描述不同的場景，下面我們一一介紹一下。

四張核心圖

系統(tǒng)上下文圖

如上圖所示，這個圖表達(dá)的是你所開發(fā)的系統(tǒng)和它的用戶以及它所依賴的系統(tǒng)之間的關(guān)系。從這個圖上我們已經(jīng)看出來C4圖形的幾個關(guān)鍵圖形：

C4說穿了就是幾個要素：關(guān)系——帶箭頭的線、元素——方塊和角色、關(guān)系描述——線上的文字、元素的描述——方塊和角色里的文字、元素的標(biāo)記——方塊和角色的顏色、虛線框（在C4里面虛線框的表達(dá)力被極大的限制了，我覺得可以給虛線框更大的擴(kuò)展空間）。

通過在不同的抽象層次上，重新定義方塊和虛線框的含義來將我們的表達(dá)限制在一個抽象層次上，從而避免在表達(dá)的時候產(chǎn)生抽象層次混亂的問題。

那么在系統(tǒng)上下文圖里，方塊指代的是軟件系統(tǒng)，藍(lán)色表示我們聚焦的系統(tǒng)，也就是我開發(fā)的系統(tǒng)（也可能是我分析的系統(tǒng)，取決于我是誰），灰色表示我們直接依賴的系統(tǒng)，虛線框表示的是企業(yè)的邊界。通過這些圖形化的元素表達(dá)我們可以看出來各個系統(tǒng)彼此之間的關(guān)系。

容器圖

當(dāng)我們放大一個系統(tǒng)，就會看到容器，如上圖所示，C4模型認(rèn)為系統(tǒng)是由容器組成的。我個人認(rèn)為，容器是C4模型最大的創(chuàng)舉，尤其是在這個單體架構(gòu)快速崩塌的時代。所謂容器，既不是Docker的容器，也不是JAVAEE里的容器，而是借用了進(jìn)程模型，代指有自己獨立進(jìn)程空間的一種存在。不管是在服務(wù)器上的單獨進(jìn)程空間，還是在瀏覽器里的單獨進(jìn)程空間，只要是單獨的進(jìn)程空間就可以看作一個容器。當(dāng)然如果你容器化做得好，Docker的Container和這個Container可以一一對應(yīng)。有了這個概念的存在我們就可以更清晰的去表達(dá)我們的架構(gòu)，而不是總是用一些模糊的東西。

組件圖

當(dāng)我們放大一個容器，我們就會看到組件，如上圖所示。組件在這里面很好的把接口和它的實現(xiàn)類打包成一個概念來表達(dá)關(guān)系。我個人覺得有時候一些存在于代碼中，但又不是接口的某些東西，比如Service、Controller、Repository之類也可以用組件圖來表達(dá)，如果你學(xué)了一些沒有明確抽象層次的架構(gòu)知識或者一些單體時代的遺留經(jīng)驗的時候，你可以畫出來一些組件圖，來印證自己的理解，如下圖，是我畫的自己對DDD戰(zhàn)術(shù)設(shè)計里面的一些概念的理解：

比起模糊的堆砌在一起的文字，這種表達(dá)要清晰的很多，哪怕我的理解是不對的，也容易指出和討論。

代碼圖

代碼圖沒什么可說的，就是UML里的類圖之類很細(xì)節(jié)的圖。一般是不畫的，都是代碼生成出來。除非非常重要的且還沒有寫出代碼的組件才畫代碼圖。

以上就是C4的核心圖，我們可以看到四種不同的抽象層次的定義會讓我們更容易固定住我們討論的層次，這點上我覺得C4是非常有價值的。

三張擴(kuò)展圖

架構(gòu)設(shè)計設(shè)計要考慮的維度很多，僅四張核心圖是不夠的，所以作者又提供了三張擴(kuò)展圖，可以讓我們關(guān)注更多的維度。

系統(tǒng)景觀圖

看得出來，系統(tǒng)景觀圖是比上下文圖更豐富的系統(tǒng)級別的表達(dá)。不像上下文圖只關(guān)注聚焦系統(tǒng)和它的直接關(guān)系，連一些間接相關(guān)的系統(tǒng)都會標(biāo)示出來，那些系統(tǒng)的用戶以及用戶之間的關(guān)系也會標(biāo)示出來，只是內(nèi)部的用戶會用灰色標(biāo)記。

這個圖有什么用呢？在我們分析一個企業(yè)的時候，我們需要一個工具幫助我們把一家公司給挖個底掉，做到完全窮盡，才能看到企業(yè)的全景圖，從而理解局部的正確定位以做好局部設(shè)計為全局優(yōu)化服務(wù)。之前我試過以四色建模的紅卡、事件風(fēng)暴的事件兩種工具來教人掌握這種能力，一般來說，程序員學(xué)員都無法快速掌握這種順藤摸瓜的分析技巧，畢竟跟程序員的思維還是有些差異的。但是用了系統(tǒng)景觀圖之后，學(xué)員就毫不費力的掌握了這種分析能力，所以我后來都是用這個圖來教程序員探索企業(yè)的數(shù)字化全景圖，效果極好，推薦給大家。

動態(tài)圖

動態(tài)圖不同于其他表達(dá)靜態(tài)關(guān)系的圖，它是用來表達(dá)動態(tài)關(guān)系的，也就是不同的元素之間是如何調(diào)用來完成一個業(yè)務(wù)的。所以動態(tài)圖不僅僅適用于一個層面上，它在系統(tǒng)級、容器級和組件級都可以畫，表達(dá)的目標(biāo)是不一樣的。

我之前曾經(jīng)寫過名為《像機(jī)器一樣思考》的一系列文章，在文中也發(fā)明了類似的圖，不同于本文中關(guān)系線上標(biāo)注的是調(diào)用的方法、函數(shù)，我更關(guān)注的是數(shù)據(jù)，使用效果也很好。

什么時候用動態(tài)圖呢？舉個小例子，我之前做一個內(nèi)部的小系統(tǒng)，團(tuán)隊中只有一個有經(jīng)驗的工程師帶著十多個畢業(yè)生，我便要求他們在開始工作之前都畫出動態(tài)圖來，交由有經(jīng)驗的工程師去評估他們的思路是否正確，如果有問題，就在開始之前就扼殺掉爛設(shè)計。不管是畢業(yè)生還是初級工程師，改代碼的能力都比寫代碼的能力要差很多，所以將爛設(shè)計扼殺在實現(xiàn)之前還是有幫助的。

部署圖

前面的幾張圖都是站在開發(fā)的角度思考，但是一個沒有充分思考過部署的架構(gòu)很容易變成一個運維的災(zāi)難。所以作者提供了一個部署圖。考慮到DevOps運動如火如荼，這個圖可以變成很好的Dev和Ops之間溝通的橋梁。我們在實操中發(fā)現(xiàn)，Dev和Ops關(guān)注點的不同、語言的不一致，在這張圖上表現(xiàn)得非常清楚。

圖上最大的的實線框不同于虛線框，它表達(dá)的是數(shù)據(jù)中心，當(dāng)你開始考慮異地載備的時候它就有了意義。數(shù)據(jù)的同步、實例的數(shù)量都會影響部署圖的內(nèi)容。部署圖基本都是容器級的，它能很好的表達(dá)出來容器到底部署了幾個實例，部署在什么樣的操作系統(tǒng)上，一個節(jié)點部署了幾個容器之類，我們在實際使用中，發(fā)現(xiàn)需要考慮的信息太多，自己就抽象出了類似于亞馬遜上實例規(guī)格的Small、Large之類的術(shù)語來表達(dá)機(jī)器配置，增進(jìn)了開發(fā)和運維之間的交流準(zhǔn)確性。

為什么C4值得推薦

夠直觀，對于程序員來說容易理解，容易使用。

我們在開頭的時候說過，只有每個人腦子里的才是架構(gòu)圖，如果我們使用一個本身就很難達(dá)成一致理解的工具，那成員就會陷入理解的死循環(huán)。經(jīng)過嘗試教授不同工具，發(fā)現(xiàn)C4模型是最容易理解、最容易使用的工具。可能它的概念是復(fù)用了程序員已有的一些認(rèn)知模型，程序員在學(xué)習(xí)后都可以迅速的使用起來，并問出一些高質(zhì)量的問題。

總結(jié)

在思維的世界里，我們都是盲人，很多東西我們以為自己知道，實際上畫出來之后，才發(fā)現(xiàn)很多東西沒想到，或者想的是亂的，同時別人也才可以給我們反饋。

有了上面的這個工具，我們就可以開始可視化的架構(gòu)設(shè)計之路了，但路上還有一個心魔需要戰(zhàn)勝。在我們的文化里，出錯是一件很丟人的事情，所以我們喜歡用一些模糊的描述避免被別人挑戰(zhàn)，而可視化是讓我們精確的描述出自己的理解，來歡迎別人的挑戰(zhàn)。這一個坎不太容易跨過去，但是一旦跨過去、大家形成正向的互動之后，我們的進(jìn)步速度會變得很快，從而把封閉的人遠(yuǎn)遠(yuǎn)的甩在后面，獲得組織級的成長推力。我自己就在跟別人的交流之后獲得了更深入的洞見，本文已經(jīng)分享了一些，還有一些內(nèi)容后續(xù)再跟大家分享。

注：文中圖片均來自：https://c4model.com/

文/ThoughtWorks仝鍵

原文：https://insights.thoughtworks.cn/c4-model/