資料驅動設計 - 重新思考 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 後，透過幾次會議大致上可以理解客戶對於物流的處理，也得到「這個系統非常複雜，但能涵蓋他們大多數客戶需求」這樣的資訊，因此一直認為客戶只需要處理空運的部分，提出一些調整意見後，就依照客戶原有系統的資料表規劃開始開發。

然而，在處理其他需求時才發現，這套系統只能適用客戶裡面特定的客戶，因為他們還有陸運、海運的情境，這在看到資料表以及討論時都沒有得到這樣的背景資訊，因為缺少脈絡而無法給出恰當的設計。

架構師的角色跟工程師不同的地方在於，會需要搜集利害關係人的需求來做全面性的分析，並不一定能夠單靠技術解決問題。當時以乙方的角色很難提出這樣的要求。再加上後續得知客戶其他業務單位以繁忙拒絕事前的需求訪談，讓整個系統只能針對當下有需求的部門設計。