可能性 - 重新思考 Rails 架構

近年在台灣使用 Ruby on Rails 的專案逐漸減少，然而在其他國家仍有許多專案使用。這一系列的文章試著從不同的角度看待 Rails 開發的可能性，就是希望能挖掘出更多應用情境。

規模化

Rails 是一個能很好規模化（Scalability）的一個框架，這裡指的不是開發大規模系統，而是讓大多數的工程師都能夠參與到開發中。

大多數專業能力發展到一個階段，就會需要將這些技能傳遞給其他人來做更多、更複雜的任務，那麼勢必會需要簡化和抽象化許多細節。而 Rails 容易入門與優秀的開發速度，就很好體現了這一點，也是到現在仍有許公司選擇 Rails 的原因。

然而，這也成為 Rails 框架的一大弱點，一但我們習慣這樣簡化的系統後就很可能停滯在某個階段沒有明顯的進步，而造成環境中只有熟悉基本使用的新手與突破各種難關的專家，反而很少有中階的工程師存在。

拆解細節

要改善這樣的問題，我們可以從拆解一個框架的細節來著手。這並非要我們針對每一行程式碼閱讀，而是去探討一個框架提供了哪些能力，將怎樣的問題封裝起來。

舉例來說，在 Ruby 中基本上是以 Rack 定義的介面作為 HTTP 伺服器的標準，在處理一個 HTTP 請求的過程中，並不會幫我們處理傳入的參數、判斷內容格式（Content-Type）和正確解析，然而使用 Rails 時則自然而然的都變成 ActionController::Parameters 物件，讓我們可以以 Hash-like 的介面進行操作。

簡單來說，Rails 幫助我們將開發 Web 應用所需的 HTTP 協定、資料庫、內容算繪（Render）等情境都做了一定抽象化，我們只需要依照慣例（Convention）或者說約定好的介面（Interface）就可以很簡單地進行實踐。

更進一步

當我們了解到了這些議題後就自然會發現，開發框架基本上是幫我們處理了「基礎建設」的部分，要更進一步將整個商業邏輯放到裡面，是不足的。

這也衍伸出了這系列的議題，當我們的開發活動是圍繞在框架本身而沒有更加深入的區隔出職責（Responsibility）的時候，是否仍然只處理了非常表面的問題。也因此，從 Clean Architecture 的角度來看，在入門 Rails 所學會的技巧並未觸及到 Use Case 和 Entities 兩個層面，或者說沒有「釐清」因此才會產生 Service Object 這類技巧來幫助我們進一步抽象化。

可惜的是，這些工具、套件大多是非常零碎的，也很常讓我們無法區分該以哪個方式來搭配使用。這一次以實驗性的角度看待 Rails 針對這類狀況實作能有哪些手段，多少有解決了一些套件的意圖，但是仍有許多可以改善的地方等待討論與深入。