C4 模型 - 可視化架構設計

 　　前言

　　世界上最難的兩件事是：

　　1. 把個人思想放進你的腦殼

　　2. 把你的錢放進個人口袋　　

　　第二點咱們不探討，由於這是衆所周知的，不信？過來試試：）　　

　　對於第一點，對咱們程序員來講，其實也是我我的一直強調的，不少事情的成敗，其實就在於掌舵人的思想層面是否定知是一致的，當咱們對於一個事物的認知不在同一層面，就比如咱們的划槳是不統一的，這是不能發揮最大的生產力。

　　你碰到過嗎？

　　當咱們進入一家新公司的時候，每一個人都須要對公司的業務系統進行了解，當你不得不向別人解釋系統是如何工做的，業務模塊是如何串聯的，子系統是如何各司其職的，特別是對於非技術人員來講，你會從代碼開始解釋嗎？

　　若是是這樣的話，這將是最低效且會讓人陷入無窮無盡的技術細節裏面，如何清晰描述系統讓不一樣人找到本身的關注點，將成爲難題。

　　一般咱們會從宏觀的架構設計上進行講解，然而當咱們在探討架構設計的時候，每一個人對架構的抽象層次理解都不同，抽象這種東西，提及來好像存在，可是要具體描述乃至落筆下來，仍是很是有難度的。

　　因此咱們須要的是：讓程序員和業務人員在討論系統時候，能有統一的維度和統一標準，這就像是領域驅動設計裏面所提倡的統一語言，讓全部人在統一的認識中有效的溝通。

　　鑑於這樣的背景，C4 model提出這樣的概念來解決這個問題。

　　C4 模型

　　C4的理念是，具體把系統分爲：System Context（上下文）, Container（容器）, Component（部件）, Code（代碼）這四層，每層表明着不一樣的視圖架構，關注點也會不一樣，因此每層適用於不一樣的人員，咱們會針對當前的人員的角色，找到共同的關注點（合適的層級）來統一認識，而後拓展話題。

　　當咱們使用C4模型來描述本身的軟件架構時，能夠經過不停的放大，把架構從宏觀到細節具體地描述出來。就比如咱們看地圖同樣，總覽（System Context）關注的是國家層面，而後到省（Container）的層面，由多個省來構成國家，再下一層，到市（Container）,再到市是如何建設起來的（Code）。這四種不一樣的抽象層次的定義會讓咱們更容易固定住咱們討論的層次以及共同認識。

 

 

 

　　咱們來看一下每一層的具體含義。

　　第一層 -  System Context

　　在這一層，咱們將不會關注細節，這裏提供的是系統級別的總覽關係圖，這層的關注點應該是用戶和系統的交互，而不是協議，技術點等一些具體的體現。因此它的使用人羣是非技術人員，這裏面描述的是系統級別的交互，誰使用。

 

　　在這裏，咱們能夠理解這是一個可供終端用戶使用的完整系統（或者多個系統）的描述和專一於該層的使用人員，這裏的一個系統可由一個或者多個服務（進程）組成，能完成咱們業務的服務組合。因此看到咱們用戶直接面對的是可用的系統，而一些郵件和權限系統，則屬於子系統。

　　在這裏的一些特定技術術語須要澄清一下：一個系統可由多個服務（微服務）組成，也可只有一個服務組成（郵件系統極可能只有一個郵件的收發服務）。

　　須要特別注意的是，在跟別人探討這層的時候，儘量不要引入技術術語，由於這層更多的是使用人員關注的，你們的認知應該是在對系統的正常理解。

　　第二層 - Container

　　這一層是上一層Context的繼續（咱們這裏選擇的是用業務系統這個系統做爲例子），是咱們將各個System Context放大(Zoom in)的效果，咱們將會看到一個技術棧以及各模塊的一個職責和依賴。

   

　　這層是給具備技術背景的人員看，這裏面描述的是進程級別的應用，這是可直接部署和運行的，經過這層，咱們將能夠看清軟件總體形態以及職責描述。

　　這裏的Container也能夠理解爲容器，由於咱們的應用進程也是按容器爲單位部署的。

　　第三層 - Component

　　 這一層是Container層的繼續放大，這裏將看到服務的具體組成，如咱們的訂單服務包含哪些職責的類

　　咱們能夠看到，這一層是給開發人員看，這裏描述的是系統組成部件、部件之間的層級關係和依賴。

　　這層的Component，能夠理解爲java裏面的包或者c#裏面的程序集，這裏描述的是內部的包/程序集相互引用（調用）關係以及包對外部系統的程序的依賴

　　第四層 - Code

　　這一層是持續將Component放大的效果（借用一下官網的類圖：））。

 

　　這一層的使用對象是開發人員，這裏描述的是基於UML等圖形來描述實現的技術細節，直接反映了代碼層面。

　　找到共同語言

　　好了，當咱們把整個系統經過經過C4 模型設計把不一樣層次的抽象軟件架構描述了出來，咱們能夠找到各自所關心的層次進行快樂的交流了。

　　什麼？你想給剛來的產品經理講Component級別的架構？不，你不想，你也不能想，由於他並不關心這個，你能講的，就是基於Context級別，講述咱們公司的整個產品體系是如何運行以及關聯依賴的。

　　因此，回到咱們的前言：讓全部人在統一的認識中有效的溝通。這讓咱們在探討以前，先找好各自關心的層次，而後再進行交流。這也是C4 模型給咱們帶來的巨大價值。

　　咱們如何落地？

　　說了那麼多概念，能夠來點乾貨了，如何動手把腦殼中的架構展現出來？

　　PlantUML

　　什麼是PlantUML? PlantUml是一個支持快速繪製的開源項目，其定義了一套完整的語言，經過文字、代碼等工具用於實現UML關係圖的描述。

　　經過PlantUML，咱們能夠輕鬆經過代碼形式畫出本身想要的圖形。　

　　這裏採用一個流程圖做爲例子：　

@startuml
用戶 -> 認證中心: 登陸操做
認證中心 -> 緩存: 存放(key=token+ip,value=token)token

用戶 <- 認證中心 : 認證成功返回token
用戶 -> 認證中心: 下次訪問頭部攜帶token認證
認證中心 <- 緩存: key=token+ip獲取token
其餘服務 <- 認證中心: 存在且校驗成功則跳轉到用戶請求的其餘服務
其餘服務 -> 用戶: 信息
@enduml

　　

　　PlantUML不只僅能畫出C4 模型架構，還能輕鬆畫出經常使用的UML圖，以及經過安裝插件，實現draw.io ，xmind等插件的圖形繪畫。

　　使用PlantUML刻畫C4

 　　在VSCode中下載PlantUML插件，而後在GitHub上搜索一些好用的PlantUML開源庫，直接代碼形式畫圖吧。

 

 　　補充我的上面圖形的PlantUML源碼：）

 　　總結

　　軟件架構圖是一種很是好的表達方式，能夠用它們來表達你將如何構建一個軟件系統或者現有的軟件系統是如何工做的，而C4 模型則能很好的解決這個問題，它是由一系列分層的軟件架構圖組成，這些架構圖用於描述不一樣層次的不一樣的抽象，每層的抽象都會有不一樣的適用人羣。

　　當咱們擁有了C4 模型的方法論以後，面對不一樣角色人員，咱們將清楚的知道，應該宣講哪層以及該把關注點放在哪層，這樣咱們將會在統一的意識層面上探討，作到意識上的統一。