![蒼時弦也](/images/avatar_huf49a82458f53859c626adf20da3bee9f_18804_200x200_resize_q90_h2_box_3.webp)
資料驅動設計 - 重新思考 Rails 架構
當時收到新客戶的需求時,表示是一套很老舊的系統無法維護,急需開發一套新系統來維持業務的運作。客戶自己的工程師已經忙不過來,因此找到我當時任職的公司協助開發這套新系統,並且表示他們已經分析完畢,只需要依照 ERD(Entity-Relationship Diagram)實作即可。
何為資料驅動
這算是一個非常直覺的開發方式,畫面上出現什麼,資料庫就有對應的欄位。因此也有像是 Smart UI 這樣的名詞。
在我的經驗中,這是一個非常容易理解的方式。不論是個人網誌、新聞網站這類內容管理系統(CMS)或者購物車等電子商務系統,大多數的情境都能找到可用的對應方式。
以購物車來說,我們會在商品(Product)資料表保存的資訊不外乎品名、價格、說明等等資訊,也都會是要呈現在畫面上的內容,那麼這樣的做法在設計系統上確實是相當容易的。
Rails 的 Model
在 Rails 中,因為採用了 ActiveRecord 和 ORM(Object-Relationship Mapping),因此 Model 會直接的跟資料表對應起來,開發跟使用上都非常方便,也能很直接的讓「資料驅動」的開發過程更順暢。
因此,我有很長一段時間都會從 Model 開始設計,思考客戶的系統該有怎樣的功能、行為,然後將這些 Model 的關係繪製成 ERD 來描述關聯,在使用 Rails 或者工作上都是相當順利的過程。
然而,如果只有這樣做的話,像是 UML(Unified Modeling Language,統一塑模語言)之類的應用技巧,會在哪裡被使用呢?當時我並沒有多想這些問題。
缺少的脈絡
以資料驅動的設計很少會討論到「使用情境」這件事情,假設沒有透過其他方式(文件、測試)來補充,那麼會做出許多奇怪的設計,在 Ruby、JavaScript 這類自由度較高的語言,就很容易失去控制。
當時我們拿到 ERD 後,透過幾次會議大致上可以理解客戶對於物流的處理,也得到「這個系統非常複雜,但能涵蓋他們大多數客戶需求」這樣的資訊,因此一直認為客戶只需要處理空運的部分,提出一些調整意見後,就依照客戶原有系統的資料表規劃開始開發。
然而,在處理其他需求時才發現,這套系統只能適用客戶裡面特定的客戶,因為他們還有陸運、海運的情境,這在看到資料表以及討論時都沒有得到這樣的背景資訊,因為缺少脈絡而無法給出恰當的設計。
架構師的角色跟工程師不同的地方在於,會需要搜集利害關係人的需求來做全面性的分析,並不一定能夠單靠技術解決問題。當時以乙方的角色很難提出這樣的要求。再加上後續得知客戶其他業務單位以繁忙拒絕事前的需求訪談,讓整個系統只能針對當下有需求的部門設計。