原文位址： https://mp.weixin.qq.com/s/v7y6zW8JJZ-r4c7E6TDhQA
1 架構圖
架構圖就是用圖形的方式表達出系統不同元素之間的關系的一種形式。
元素可以有不同的粒度，如系統級别、元件級别、類級别等。
2 以終為始
文中提到：“不要為了畫一個實體視圖去畫實體視圖，為了畫一個邏輯視圖去畫邏輯視圖”。
這點深有體會，實際工作中，我們有技術方案模闆，很多人做技術方案的時候，不考慮項目的規模。
有些項目規模小不需要每個圖都畫，不需要畫的太複雜；有些人隻是按照模闆畫圖，并不清楚為什麼要畫這些圖。
是以我們畫圖之前要清楚為什麼要畫這些圖，其實如何更好的表達清楚自己的意思才是最終目的。
3 C4 軟體架構可視化模型的邏輯
C4 軟體架構可視化模型的主要邏輯：
（1）從整體到局部，從宏觀到具體（符合人類認知規律）
（2）每種圖有特定的閱聽人，針對特定的層級視角(具體文中已經給出來了)
4 思考
4.1 為什麼不是 C3 或者 C5?
是不是突然感覺像是面試中問：“為什麼 HTTP 三次握手為什麼是三次而不是兩次？” 這種感覺？
我在想，其最主要的原因于作者對用多少層可以清晰地表達架構進行了思考和取舍。
C4 架構模型通過四種層級，從宏觀到微觀，從抽象到具體，已經可以足夠表達出架構的思想。
三層表達的不夠全面，五層太過繁瑣，四層剛剛好。
4.2 C4 模型作圖的痛點是啥？
C4 軟體架構可視化模型比傳統的 UML 更簡潔，有自己很成熟的邏輯。
自己前一段時間也看過，也嘗試畫過。在畫元件視圖時，如果元件過多時，元件方框的排列非常耗時。
自己的思考：
（1）是否可以借鑒 PlantUML 那種[編碼式作圖]，作圖效率會更高
（2）或者是否可以支援類似neo4j 控制台這種圖顯示工具，更動态伸縮式圖形展示，展示效果會更好。比如我隻關心某一個控制器相關的元件，可以隐藏其他元件或者隻高亮目前元件相關的其他元件。
意外收獲
寫完文章查閱官網居然發現了支援 C4 模型的 plantuml 拓展
https://github.com/plantuml-stdlib/C4-PlantUML還推薦了其他工具
https://c4model.com/#Tooling在這裡突然想提到【先猜想後驗證】的思想，有時候我們學習某種技術之前，可以先猜想它可能是怎麼做的，核心邏輯應該是什麼，然後再去驗證是不是這樣的。
如果有相似之處，自己也會有些欣喜，能夠多一些學習技術的樂趣；如果完全不一樣，就可以比較優劣，能夠印象更深刻。
5 熟能生巧
了解 C4 模型的核心思想之後，還要多加練習，熟能生巧。
6 舉一反三
（1）是不是還可以從C 4 的不同層次之間抽象出一個層次，進而形成自己的 C5 C6 架構模型？（純粹瞎歪歪）
（2）我們在其他場景下，是不是可以可以借鑒 C4 模型的思想，來簡化一些步驟？
（3）文中提到畫架構圖常見的誤區，如為什麼用方框，實作和虛線以及顔色的含義是什麼，單個圖形的局限性等，給的了 C4 軟體架構可視化模型的方案。
文章最後說：“畫之前想好：畫圖給誰看，看什麼，怎麼樣不解釋就看懂”。
同樣地，網上有很多 DDD 圖形也存在一些問題。
由于 DDD 中概念很多，單純通過圖形或者顔色區分，尤其在圖形很大時非常容易混淆。
如《DDD 的最短學習路徑》 GitChat 的配圖
看着挺棒。
或許對于作者來說，已經畫了很多次，自己可以快速分辨出不同顔色的含義。
為了讓大家能夠了解不同顔色的含義，“貼心”地在頂部提供了圖例。
但對于讀者來說，依然需要反複核對圖例來區分不同顔色的含義。
那麼為什麼不能像圖中紅色部分“<實體>”那樣，将領域服務、領域能力、值對象直接标注在方框内呢？
有人可能會說，都寫挺麻煩的啊。
但是作圖的目的不就是讓讀者能更快速而又準确地了解你要表達的意思嗎？
而且對于作圖工具來說，同樣類型的元素，我們完全可以通過複制粘貼的方式，并不是每個相同的元素都要重複敲一次 title。