通用化功能 - 重新思考 Rails 架構

在專案初期客戶有提到，第一階段要處理的客戶是最複雜的，只要能夠解決這個客戶的需求，未來就能夠讓客戶服務的其他客戶都能夠使用這套系統。

多租戶設計

在現代軟體服務的生態中，需要以多租戶（Multi-Tenancy）的方式提供不同客戶獨立的系統是很常見的，差別就在於提供的方式跟架構。

在過去，可能會是在客戶的機房安裝軟體來提供服務。到了雲端時代，就會是使用者透過網路來使用這個系統，而不需要自己維護硬體和軟體的更新。根據隔離程度也會有不同的設計，可能是完全獨立整個環境、使用獨立的資料庫，或者透過限制查詢來隔離。

在處理這套系統時，我們其中一個任務就是讓客戶可以根據不同的客戶去切分環境提供服務，不過在開發初期可能只會有一個客戶使用到，因此以專注在特定客戶的需求為前提進行。

客製化

客製化也是一個很常見的情境，購買套裝軟體、使用雲端服務不一定能夠完全的涵蓋需求，那麼就會有根據需求調整的情況，這也是為什麼有這麼多現成軟體、服務，仍會有同類型的產品出現，主打不同的特色。

然而，在我們要開發一套多租戶系統時，這就變成一個難題。一種選項是提供標準的功能與平價的收費，大部分客戶可以被滿足，再針對不同客戶個別提供客製化的選項。或者是將一套系統的功能開發到非常強大，讓使用者可以根據需求調整或組合所需的功能來使用。

前述這兩種情境會根據客戶的需求有所不同，像銀行這類對資安要求較高的產業，可能會更偏向於前者的客製化產品，而且可以獨立部署在自家機房

需求分析

要設計怎樣的系統，就需要充分的了解使用者的需求。以 Rails 的生態系來說，也有不少多租戶產品的案例。

根據客戶的需求，要翻新一套舊系統、提供給不同客戶使用、有一套複雜的機制等等，選擇用 Rails 開發在技術上並不算是一個有問題的判斷，然而如何將系統上的功能和機制設計正確，反而在第一階段完成後，才發現是一個大問題。

在這個專案中，和我們接洽討論的只有一個業務單位，同時在設計初期其他業務單位也不願意參與進來討論，再加上過去客戶對不同客戶的需求，是採取個別客製化的方式（在雲端出現前很常見）那麼整個開發過程中，我們實際上只釐清單一客戶的需求。

這也演變到後來我們很難轉變成一個通用的服務提供給客戶的其他客戶使用，當時我們認為從客戶給的 ERD、功能需求等資訊，是一個專門處理「空運」情境的系統，然而在第二個業務單位加入後，卻多了陸運、海運的情況，而且紀錄運輸節點的方式也有不少差異，這就造成原有的設計完全無法被使用。

簡單來說，即使我們有再好的系統架構和設計，只要無法正確理解使用者實際的需求，最後都會變成不適合的架構。