1. 首頁 > 生活百科 > >

京東云開發者｜軟件架構可視化及C4模型：架構設計不僅僅是UML

生活百科

軟件系統架構設計的目標不在于設計本身，而在于架構設計意圖的傳達 。圖形化有助于在團隊間進行高效的信息同步，但不同的圖形化方式需要語義一致性和效率間實現平衡 。C4模型通過不同的抽象層級來表達系統的靜態結構 ， 并提供了最小集的抽象建模元素 ， 為設計人員提供了一種低認知負載、易于學習和使用的高效建模方式 。
 1 為什么要進行架構可視化？軟件系統架構設計的目標不在于設計本身，而在于架構設計意圖的傳達 。如果不能清晰、一致的在干系人間進行設計意圖的同步，即使再好的設計也只是空中樓閣 。軟件架構設計本質上也是一種抽象和建模的過程（對模型和抽象的本質參考文章《 領域驅動設計開篇 》），軟件架構設計模型的表達有多種方式：圖形化、語言和文字 。絕大部分場景下，圖形化在架構設計的表現力層面效果更佳 。因此，對于軟件系統架構進行可視化表達是有價值，且是必要的 。
軟件架構可視化的方式有多種，不同的團隊有不同的實踐方式，最為常見的由如下幾種：
?線框圖：通過線框圖和連線表達架構元素及之間的關系?UML：統一建模語言，表達系統的靜態結構和動態行為?草圖：非正式的圖形【京東云開發者｜軟件架構可視化及C4模型：架構設計不僅僅是UML】不同的可視化方式各有優劣 ， 以下部分將對不同的表現形式進行說明
1.1 可視化方式-線框圖線框圖是最為通用的可視化表達方式之一 ， 架構師或設計人員大量的架構圖 ， 比如技術架構、功能架構、數據架構、邏輯架構等等都通過線框圖的形式表達 。該種可視化方式的優勢是：
?建模工具多樣化：你可以基于Viso、Drawio、PPT等任何一款支持線框圖的軟件進行建模工作?學習成本低：設計人員幾乎不需要進行專門的建模語言以及建模工具的學習，門檻較低但，基于線框圖表達軟件系統架構存在的問題也非常明顯：語義的一致性問題
你可能自己畫過很多軟件系統架構圖，也可能參與評審過其他團隊的架構圖，我相信，對你而言并不是的所有的圖都是“清晰且易于理解的” 。舉個簡單的場景，如果我們在百度搜索 “架構圖” ，你可能得到以下結果：

京東云開發者｜軟件架構可視化及C4模型：架構設計不僅僅是UML

文章插圖
各式各樣的 “架構圖”：不同形狀和顏色的圖形元素、不同形狀和顏色的連線、不同的意圖 。
我們可以看出：線框圖雖然簡單，但其其圖形化的語義一致性是大問題 。雖然都是通過線框表達軟件系統架構，但不同的人可能使用不同的元素、不同的顏色、不同的連線和分層等等，線框自由表達的靈活性和圖形化語義的一致性存在潛在沖突 ， 最終都會阻礙架構設計意圖傳達 。
1.2 可視化方式-UMLUML是統一建模語言，相比于線框圖而言，其優勢是在軟件建模層面提供了一致性的建模元語言 。簡單來說，UML提供了大家達成一致的（UML支持擴展的場景除外）建模元素 。如果團隊成員比較熟悉UML，那么通過UML表達的系統架構圖天然具有認知一致性 。
豐富靈活的建模元語言在提升語義一致性的同時，也必然會導致復雜性的上升 。掌握UML具有一定的學習成本，而熟練的應用對研發人員也提出了更高的要求 ?；?Simon Brown給出的數據，實際情況只有少數團隊真正使用UML 。不論是UML的復雜度和學習成本原因，還是敏捷化下對UML的排斥 ， 很多團隊都放棄了UML 。
我們不能否認UML的價值 ， 基于統一建模語言能夠更有效的進行架構設計的信息傳遞和溝通，也能基于UML提供的詳細的模型圖元素進行充分的設計表達 。團隊中是否要基于UML進行溝通需要權衡，雖然UML不能表達你所要傳達的全部的架構信息，但其在某些維度的表達相對比較適合 。
?表達流程和工作流可以采用UML活動圖?表達運行時的交互可以采用UML時序圖?表達領域模型或者設計模式可以采用UML類圖?表達狀態轉換可以采用UML狀態機?表達系統的部署結構可以使用UML部署圖1.3 可視化方式-草圖架構可視化另一個非常常見的方式是：草圖 。草圖是一種非正式的、易于快速溝通的圖形化方式 。團隊基于特定的場景，可以通過草圖的形式進行快速的溝通，以便高效的在干系人間拉齊關鍵信息 。
但，草圖的劣勢與線框圖一樣：語義一致性低
我們可以在白板上 “隨心所欲” 的畫各式各樣的草圖 ， 草圖上的元素、連線，又或者布局都可能是涌現式的、臨時性的，這些草圖的價值在于 “會話周期內的高效溝通” 。如果干系人沒有完全參與到草圖的討論，又或是后置查看 ， 大概也很難精準捕獲這些草圖所要表達的設計意圖 。

推薦閱讀