軟件架構系列一：C4模型

時間 2020-05-11

原文原文鏈接

本文要點預覽：由於軟件系統的分佈式特色以及開發團隊的分佈性，瞭解軟件架構的基礎變得愈來愈重要。而在過分設計和毫無設計之間，咱們應該把注意力放在對軟件系統有重大影響的決策和權衡上。好的架構師應該是團隊的活躍分子，不只可以進行代碼協做，還能爲團隊提供技術指導。軟件架構中的溝通環節極具挑戰性。C4 模型對軟件架構中的溝通環節進行告終構化，從一個上下文圖表開始，再逐步深刻到系統的各個技術層面。實際上，能夠多花一些時間實現好的架構，好的架構可以帶來敏捷。html

隨着軟件行業的發展，開發團隊仍然面臨着與軟件架構有關的問題。這些問題比以往任什麼時候候都要來得突出，由於咱們如今構建的系統愈來愈趨於分佈式化，開發團隊也愈來愈分佈式化。爲了解開這些迷思，開發者須要瞭解如下五個與軟件架構有關的事實。web

1. 軟件架構不僅是前期的「大設計」數據庫

傳統的觀點認爲，軟件架構就是在前期進行「大設計」，而後經過瀑布模型進行交付，架構團隊要確保軟件的每個元素在進行編碼以前都要考慮穩當。編程

2001 年，「敏捷開發宣言」建議咱們「擁抱變化而不是遵循計劃」，但這個觀點後來卻被誤讀成不該該制定任何計劃。結果就是，有些開發團隊直接從原先的「大設計」變成了零設計。瀏覽器

這兩種極端的行爲都愚蠢至極，實際上，在某個時候，你會發現前期的設計並不是開發出完美軟件的必要因素。前期的設計應該只是一個起點，或是做爲團隊前進方向的指引。安全

在進行軟件設計時須要作出一些設計決策。在談及軟件架構和軟件設計之間的區別這個問題時，Grady Booch 說，「架構表明了重要的決策，決策的重要程度經過變動成原本衡量」。
換言之，就是看在後續進行變動時那個決策須要付出更大的成本。因此，好的前期設計就是要充分理解什麼是「重要的決策」。這些決策一般與技術選型和結構（也就是分解策略、模塊化、功能邊界等）有關。服務器

若是開發的是一個單體系統，那麼選擇何種編程語言可能就變得尤其重要。若是採用的是微服務架構，那麼使用何種編程語言就變得不那麼重要，但須要考慮其餘方面的因素。相似的，若是採用了六邊形架構，雖然能夠將業務邏輯與技術選型解耦開來，但仍然須要作出其餘方面的權衡。架構

因此說，前期設計就是要了解影響軟件成型的重要決策，而不是具體的技術細節，好比數據庫的某個列要設置多大的長度。在現實當中，我會讓團隊真正去了解他們將要作什麼、如何去作以及他們已經設計好的東西是否可行。可讓他們識別出最高優先級的任務，若是有必要能夠寫出代碼。總而言之，前期設計就是一個疊加成功概率的過程。編程語言

2. 每一個開發團隊都須要進行軟件架構分佈式

上述的內容適用於每個開發團隊，從一個單人團隊到數百人的分佈式團隊。設置起點和方向其實就是要創建技術領導力。若是作不到這一點，就可能出現混亂：結構混亂的代碼庫（典型的「大泥球」），難以理解，難以維護，質量不達標，如性能、伸縮性或安全性。簡而言之，任何一個開發團隊都須要技術領導力。

3. 軟件架構師要會寫代碼、指導他人以及參與協做

在大部分人看來，軟件架構師就是給開發團隊下達指令的人，就像接力賽中跑第一棒的人。但事實不是這樣的，現代的架構師喜歡編碼、指導他人並參與協做。我所碰見的好架構師也都是好的開發者，他們仍然喜歡編碼，最起碼他們並不想放棄編碼工做。

由於變化太快，人們很容易就與技術失之交臂。但我認爲軟件架構師應該是「建築大師」，在必要的時候他們仍然能夠寫代碼。做爲團隊的一份子，編碼會讓架構師的工做變得更容易一些，由於編碼有助於架構師理解系統，並且團隊的其餘成員會真正把架構師當成是同事。

須要注意的是，軟件架構師不必定要指定某我的來擔任。剛開始能夠這樣作，但其實也能夠由多我的共同承當這個角色。但要注意，創建協做式的技術領導力並非件垂手可得的事。軟技能原本就不是很輕鬆就能得到的。

我曾經組建 2 到 5 我的的架構師小組，讓他們來設計軟件系統，但他們在與技術和設計決策方面沒法達成共識。在極端狀況下，個性衝突會致使小組解散。關鍵是要了解你的團隊，並確保應用了恰到好處的技術領導力。

4. 不必定非要用 UML
傳統的軟件架構一般包含大量的 UML 模型圖，試圖充分展示軟件系統的每個細節。惋惜的是，建模和 UML 在很大程度上與前期「大設計」相耦合，而這些技術在近幾年已通過時了。如今徹底不懂 UML 的軟件開發團隊比率在逐步上升。

現現在，大部分人只是「在白板上畫幾個方塊和線條」，並將其做爲溝通想法的手段。在過去幾年，我參與過的軟件架構小組畫過大量這樣的圖表，我把它們拍成照片，有好幾個 G。我敢說，從行業角度來說，咱們已經散失了軟件架構的溝通能力。我見過不可勝數的圖表，它們有些是隨機着色方塊和線條的組合，模糊不清，難以辨認。若是一個團隊沒法就軟件架構進行溝通，那麼就沒法設置起點和創建技術領導力。

我建議使用「C4 模型」來進行軟件架構方面的溝通——上下文（Context）、容器（Containers）、組件（Components）和代碼（Code）。其本質是建立一系列結構化、可伸縮的圖表來描述軟件系統。爲每個軟件系統建立一個上下文圖表，用於描述軟件系統與真實世界之間的關係。而後放大系統邊界，讓內部的容器突顯出來——容器就是可部署、可運行的實體，好比運行在瀏覽器上的單頁應用、服務器端的 Web 應用、微服務、數據庫實例，等等。若是有必要，能夠再將每一個容器放大，讓容器內部的組件突顯出來。最後，你也能夠放大組件，讓代碼級別的元素（類、接口、函數、對象等）也突顯出來。C4 模型獨立於具體的表示方法，雖然我傾向於使用簡單的「方塊和線條」，但使用 UML 來表示也是能夠的。

www.4model.com 提供了更多的信息、視頻、示例圖表和工具連接。若是你的團隊正糾結於軟件架構溝通方面的問題，那麼能夠看看這些資料。

5. 好的軟件架構是敏捷的

如今仍然存在一種誤解，認爲「架構」和「敏捷」之間是一種競爭和衝突的關係。但其實不是的。相反，好的軟件架構也是敏捷的，它有助於應對業務變動，無論是需求變動、業務流程變動仍是混合變動。固然，什麼纔是「好的架構」仍然有待商榷，但我認爲，好的架構與好的模塊化息息相關。若是你曾經有過在「大泥球」上進行變動的痛苦經歷，那麼你就會知道，好的代碼庫結構（好的模塊化）是多麼的重要。

現現在，不少團隊都存在一個很大的問題，他們採用了一種叫做「架構中立的設計」，George Fairbanks 在他的「Just Enough Software Architecture」一書中對此進行了描述。換句話說，他們採用了一種不須要考慮權衡因素的架構風格。在現實中，開發團隊使用微服務架構代替單體代碼庫。但實際上，他們有多是建立出了一種「分佈式的大泥球」，可見軟件設計和分解過程是多麼的重要，無論是要構建一個單體仍是一個微服務架構的系統。敏捷和好的軟件架構不是那麼容易就能實現的，它須要一些精巧的設計，也須要做出一些權衡。這也再次說明爲何設置起點和創建技術領導力是如此的重要。

關於 C4 模型的一些解釋
C4 模型是來自 software architecture for developers 一書的定義，指的是 Context 上下文場景、Container 容器、Component 組件和 Classes 類（或者 Code 代碼），意思指一個軟件架構是由這些模型呈樹形結構組成。

關注代碼仍然是大多數軟件開發生命週期中關注的焦點，這是有必定道理，由於代碼是最終交付。但若是你不得不向別人解釋關於系統是如何工做的，你會從代碼開始解釋嗎?

確實代碼並不能講述系統的整個故事，在缺少文檔的狀況下，人們一般會開始在白板上或紙上用圖框和線條解釋系統的主要構建塊是什麼，它們是如何鏈接的。而使用 Microsoft Visio, Rational Software Architect 或 Sparx Enterprise Architect 等專業工具又比較複雜。

更好的辦法是在不一樣的抽象層次建立不一樣的圖 diagram，一個簡單的圖 diagram 比複雜的圖可以更有效表達描述。下圖是 C4 模型的示意圖：

類 Class: 這是面向對象世界經常使用, 類是咱們系統最小的構建模塊。

組件 Component: 一個組件能夠認爲是由一個或多個類組成的邏輯組，好比一個審計 audit 組件或受權服務可以用於決定資源的訪問是否被容許，組件典型地由許多協同類組成。微服務架構能夠認爲是一種組件。

容器 Container: 一個容器表明組件執行或駐留的地方，這多是一個Web容器或應用服務器，也能夠是富客戶端應用或數據庫，容器是作爲系統一部分啓動的，容器之間通信是經過遠程接口如 SOAP web service, RESTful interface, Java RMI, Microsoft WCF, messaging等進行， Docker 能夠認爲是一個這樣的容器。

Context/系統System: 一個系統是一個高層次抽象和表明，一個系統由多個單獨的容器組成，好比財務系統，銀行系統或網站系統等。

以上解釋來自 jdon.com。