[Architecture] 系統職責的混搭不是流行,而是災難

我雖然自問不怎麼時尚,但多少也聽過時尚圈流行混搭 (mashup),尤其是服裝的穿著,走在都會的街上想不碰到混搭穿著的人還蠻難的,這樣的穿法是時尚的表現,但是如果系統架構也這樣,可就一點也不時尚,反而會埋下很多的地雷給自己踩 ...

我雖然自問不怎麼時尚,但多少也聽過時尚圈流行混搭 (mashup),尤其是服裝的穿著,走在都會的街上想不碰到混搭穿著的人還蠻難的,這樣的穿法是時尚的表現,但是如果系統架構也這樣,可就一點也不時尚,反而會埋下很多的地雷給自己踩 ...

物件導向的系統分析法以及之前我在文章中提到的 "單一職責原則 (single responsibility principle)" 不是隨便說說的,單一職責原則讓程式碼之間沒有強烈的耦合性,讓它便於切割與組裝,而單一職責原則的前提是,在設計時就要職責分明,簡單的說,就是 "該做什麼就做什麼,不需要額外的東西",以 MVC 架構來說,M 是負責 Model,V 是負責資料呈現與使用者介面,而 C 是協調與控制 M 和 V 的整合工作。一個具有 MVC 架構的程式,它們的 M/V/C 都是職責獨立,並不相互依賴彼此。

然而事與願違,更多的專案內,程式碼之間 (或與資料之間) 的耦合性異常嚴重,V 要和 M 相依,而 M 要存放 V 要呈現出來的結果資料,V 又做了太多的 C (ASP.NET Web Form 的 event model 就是如此),C 又需要靠 M 才能完整的執行動作 ... 這些都是因為耦合性太嚴重所導致的現象。職責不明的程式碼很容易就牽一髮動全身,改了一個小地方會讓整個系統崩潰,而如果資料沒有依照 V 的規格來存,那 V 就一定會呈現不對的資料 (例如 Y/N,用一個 bit 就可以存,但就有人愛用 varchar(3) 或 varchar(1),把資料庫當 V 來用了)。這種系統我也看了不少,若是初學者寫出這樣的系統還可以來的及試著導正觀念,但若是出自一個已工作數年的開發人員手裡,那 ... 自求多褔可能比較好。

因此,在系統架構上應用單一職責原則以及職責分離的思維來設計,在無形中能強化整個系統的體質,並且讓系統具有物件導向的高彈性,也不會再出現牽一髮動全身的風險,明確的將各個模組的職責都切開,也有助於日後的維護工作,再結合單元測試與整合測試,那麼整個系統的服務品質 (service quailfy) 會提升很多。如果是公司的舊系統,也許當下無法改變,但改變是一滴一滴累積的,可以先從小型的新專案開始做,然後慢慢的將影響力擴大,當公司想要更新系統或計畫新的系統時,就可以將這個思維注入。

若覺得程式碼的職責切分一時不習慣,可以先以資料和程式間的職責切分開始,資料應該就只是資料,而不是呈現用的資料,將資料變成報表或網頁上看到的內容,是 V 的職責,資料庫要做的就只是讓 V/C 來快速存取資料而已,其他的就不是資料庫該做的。而其他 M/V/C 之間的互動也是類似的觀念。

記住,適當的職責切割有助於系統品質提升,而不當的混搭只會挖洞給自己跳而已。