[Meetup 筆記] 如何繪畫別人看得懂的軟件架構圖？──Simon Brown 的C4 Model

作為軟件開發者，你試過看不懂別人的架構圖嗎？或是自己嘔心瀝血徹夜畫的架構圖，別人卻看不懂？

講題：The Art of Visualising Software Architecture

講者：Simon Brown （個人網站）

主辦：Agile Hong Kong

時間：2016/01/15 晚上

場地：Odd-e 在上環的新辦公室

上星期五晚出席了一個關於軟件架構視覺化的講座。講者Simon Brown 多年從事系統架構的顧問和培訓工作，也會到世界各地演講，著作有Software Architecture for Developers 和The Art of Visualising Software Architecture 。其題為”The Conflict Between Agile and Architecture — Myth or Reality?” 的演講在Software Engineering Institute 主辦的SATURN Conference 2013中，獲參予者票選為”Architecture in Practice” Presentation Award 得主。

講者Simon 首先提到敏捷開發有賴良好溝通，但在他工作和開辦工作坊的經驗中，發覺很多開發者無法有效地講解自己的構想，想傳達的資訊往往像卡在他們的腦袋裡。雖然開發者常畫圖來幫助講解，而軟件工程界也制訂了諸如UML 的建模語言和製圖規範，不過事實上大部分人都覺得UML太複雜所以很少用，尤其是高階的架構設計圖。

於是很多開發者以自己的方式畫了令人不明所以的系統架構圖。有些圖使用了意味不明的顏色和圖形（這個粉紅色的虛線想表示什麼？），有些則過多實作細節（User → UI → Calculation Engine → Data Reader → ……），有些將架構（Architecture）、運行（Execution）、部署（Deployment）等不同面向的內容混在同一幅圖裡（Import Service, cron, UNIX VM instance, …… ）。結果這些「設計圖」徒令本來要說明的構想更難理解。

針對上述情況，Simon 認為”A common set of abstractions is more important than a common notation.”，提倡C4 Model (Context, Container, Component, Class)，將系統架構分成四個層級的抽象化。一個系統會有一個Context 以及各種使用者和其他外部系統，Context 由多個Container構成（例如web app, mobile client, database, etc.），每個Container 包括數個Component ，而Component 由class 組成。

Simon 以地圖的縮放比例來類比架構圖的層級。地圖愈是放大，看到的地域愈小，但顯示的資訊愈詳細。同樣道理，低層的架構圖應顯示特定模組的細節，而高層的架構圖應隱藏細節，提供較宏觀的概覽。

構圖原素方面，採用基本的方盒、箭頭線、標籤，再按實際需要自訂添加和附上圖例。Simon 認為毋須拘泥於一套行業通用的製圖規範，個別團隊只要有一套共識的規範即可。就像各式各樣的地形圖、街道圖、觀光圖，呈現資訊的方式並不統一，但只要附上圖例說明，一般人都能夠看得懂。

Simon 表示C4 Model 並非要完全摒棄UML，在描述系統採用的Design Pattern或模組的互動時，他仍然會使用Class Diagram、Sequence Diagram。

驟眼看來，可能會覺得C4 Model 並沒有新穎獨到之處，其他建模系統例如UML 、RUP 等等早有目的類近的圖。這會不會是講者「因為現存的一百種繪圖系統不夠好，所以自己又提出第一百零一種」？

但回想UML 會少人用，就是因為規範了太多構圖細節，對高階設計圖來說太過繁瑣，不易記所以容易畫錯，而且繪圖費時，往往需要專門製圖軟件輔助。這其實是種資訊過載，構成受眾的認知負擔。

講者提倡的其實不是又一套製圖規範，而是不要倚賴規範去繪製架構圖，同時注意適當地將架構作不同層級的抽象化去分別製圖。按抽象化程度分別製圖，能配合受眾的需要隱藏不必要的資訊。不倚賴行業規範來繪製的設計圖，代表必須對設計圖能易於被理解有所自覺， 對技術背景深淺不一的團隊成員或客戶，都便於繪畫和閱讀。採用簡單的構圖原素，亦便於隨時在紙上或白板上繪畫，有利多人協作和溝通。

若想進一步了解C4 Model，可參看Simon 的演講投映片。