文章插圖
2 C4 模型2.1 C4模型的統一抽象團隊需要統一語言進行高效溝通 !!!
C4模型在不同的級別提供了統一的抽象以表達軟件系統的靜態結構 。如下圖所示：
文章插圖
?軟件系統：最頂層的抽象，其對用戶提供價值 。包含待構建的系統以及外部依賴的系統?容器：表示一個應用或者數據存儲，容器需要運行以支持系統的正常運轉 。每個容器都是獨立部署或運行的單元 ， 容器間的通信一般式跨進程交互?組件：提供一定能力封裝的單元 。在C4模型上下文中，組件不是獨立部署的單元，一般情況下運行于容器之中 。?代碼：系統的實現細節相關?人：系統的使用用戶2.2 上下文圖：System Context Diagram我們要構建的系統不會孤立存在，都會依賴現有的IT設施 。要明確我們構建的系統是什么，宏觀上需要回答：我們的系統如何融入到現有的IT設施 。
系統上下文圖正是從高層視角表述待構建系統與當前IT設施的交互及邊界 。通過上下文圖：
?展示與軟件系統交互的各方及相互關系?展示軟件系統與外部環境的邊界?作為了解系統架構的切入點?確保所有人都理解、認可系統的工作范圍
文章插圖
2.3 容器圖：Container Diargram更進一步的剖析核心系統，回答：系統由哪些容器組成？容器的職責是什么？以及相關的高層的技術選型是什么？
與Docker的容器概念不同，C4模型的容器是在 “系統” 作用域之下 ， 其表達的是組成系統的可獨立可部署的物理單元 。以下圖為例：單個容器元素重包含了名稱、職責描述、技術選型，同時，容器間的連線及標注標識了其高層的交互協議及交互形式 。
文章插圖
2.4 組件圖：Component Diagram進一步的剖析容器，回答：容器由哪些組件組成？這些組件的職責及組件間的交互形式是什么？
具體到每個容器內部 ， 通過多個組件及組件間的關系表達容器的組成 ?！敖M件” 本身是一個泛化的概念，C4模型的組件是在 “容器” 的作用域之下，其表現形式可能是獨立的Jar包 ， 或者是應用內獨立的包，也可能是類級別，但邏輯上都能夠表達一個組件的概念 。對于組件圖關鍵的是要表示清楚組件的實現選型、組件職責以及組件間的交互關系 。
文章插圖
2.5 代碼代碼處于C4模型的最低層，且是可選的，其關注的是實現相關 。C4模型并沒有對實現層面的可視化進行統一抽象，開發人員可以選擇UML類圖、E-R圖等進行可視化 。是否需要提現代碼層面研發人員基于具體情況具體分析 ， 一般情況下，如果系統中需要重點關注的部分可以考慮一些代碼級別的圖支持，比如，我們非常關注系統設計的可擴展性，則關鍵部分可能需要一些類圖表達；又或者非常關注底層數據模型，則E-R圖可以納入考慮范圍 。
文章插圖
3 C4模型實踐中的決策和問題連線表達依賴關系還是數據流向 ？
都可以，C4模型中的連線既可以表達依賴方向，也可以表達數據流向 。原則上，設計人員需要保證其清晰且無歧義 。實踐中一般通過合理的文字說明來明確的表達元素間的關系 。
Jar或類庫應該建模為“容器”？ “組件” ？
Jar包或類庫一般是鏈接到調用方的進程中，作為進程中的一部分存在 ， 這種依賴一般不表示為容器，而是組件 。當然，是否要將Jar，比如SDK表示為組件并體現在組件圖上需要設計人員具體情況具體分析 。
數據存儲系統應該建模為 “軟件系統” 還是 “容器” ？
數據存儲系統，比如MySQL、DFS等一般是作為獨立的外部存儲集群存在，集群的運維可能歸屬于公司的運維團隊 。以OSS為例，但從應用角度而言，即使集群的運維不歸屬當前開發團隊，團隊也會申請租戶隔離的專屬空間，因此，在C4模型中這種情況應該表述為 “容器” 。
消息系統應該如何建模 ？
消息系統一般作為兩個容器間的交互媒介，因此在C4模型中消息系統的建模存在兩種方式：
?依賴消息系統的容器都顯示與消息系統交互，明確的表達各自與消息系統的依賴關系或數據流向?屏蔽消息系統 ， 只提現容器間的依賴關系，并對依賴進行明確說明圖形化的過期問題
推薦閱讀
- 最新蘋果iOS個人開發者賬號注冊申請流程 申請蘋果id賬號注冊
- 奧比島:夢想國度暗夜襲擊魔藥店失竊疑云答案是什么
- 云原生之旅 - 9）云原生時代網關的后起之秀Envoy Proxy 和基于Envoy 的 Emissary Ingress
- 華為云 MRS 基于 Apache Hudi 極致查詢優化的探索實踐
- 棲云異夢金屬星球怎么擺放順序
- 云原生之旅 - 8）云原生時代的網關 Ingress Nginx
- 華為開發者大會HDC2022：HMS Core 持續創新，與開發者共創美好數智生活
- 云原生之旅 - 7）部署Terrform基礎設施代碼的自動化利器 Atlantis
- 華為開發者大會2022：HMS Core 3D建模服務再升級，萬物皆可驅動
- 云頂之弈玉龍半神狗熊陣容怎么玩