可能性 - 重新思考 Rails 架構
近年在台灣使用 Ruby on Rails 的專案逐漸減少,然而在其他國家仍有許多專案使用。這一系列的文章試著從不同的角度看待 Rails 開發的可能性,就是希望能挖掘出更多應用情境。
近年在台灣使用 Ruby on Rails 的專案逐漸減少,然而在其他國家仍有許多專案使用。這一系列的文章試著從不同的角度看待 Rails 開發的可能性,就是希望能挖掘出更多應用情境。
前面我們主要著重在寫入的處理,如果是單純寫入的處理,我們可以使用 Query 來處理。基本上 Command 和 Query 都可以看作 Use Case(使用案例)的一種,可以根據複雜程度決定是否需要細分,當我們實踐到這個階段,也接近有讀寫分離的系統所呈現的狀態。
最近在帶同事做 Temperature Reading 時拿了一個卡了一段時間的功能出來討論,過程中發現在我們學習軟體開發的經驗中,對於抽象化的訓練大多只停留在「定義一個 Animal 物件」這個層次的理解。
花了一點時間大致上讀了一遍維基百科 Abstraction 的條目,也驗證了我感受到的狀況。
在 Form Object 的階段有提過 Input Object 的概念,與之相對的則是 Output Object 的機制,這兩個物件也正好對應 Clean Architecture 中所提到的 Input Port 和 Output Port 的應用。
當我們將運送模組(取 module Shipments
的方式稱呼)的實體(Entity)確立下來後,就可以來處理倉庫(Repository)也就是我們的資料如何保存的議題。在某些軟體開發的最佳實踐中,會建議推遲資料庫的設計,就是因為一但確定後就難以修改。
依照這次的流程,我們在接近功能完成時才處理,能省去不少前期就確定資料表結構的問題。
到 Use Case 階段我們已經初步跟 Rails 框架做出區隔,建構出屬於我們的 Domain Model(領域模型)然而在 Use Case 中含有許多核心概念的處理並沒有被抽離出來,這些東西就是 Entity(實體)也就是整個領域中要處理的對象(Object)
處理完使用者的輸入後,就可以來著手實際的處理。通常會將這些實作放到 app/
目錄下,然而當我們要以一個 Domain(領域)來劃分時,使用 lib/
來放置這些實作可能更加恰當,未來要轉換框架或者搬移,就只需要移動 lib/
而不會和 Rails 綁定。
實際對運送狀態進行處理之前,我們需要將 Rails 的 ActionController::Parameters
轉換成可以使用的結構,這個結構通常可以看作是 Form Object。
有了第一個 Cucumber 撰寫的測試後,我們對於更新運送狀態的行為有一定的概念,那麼就可以針對這個機制來進行 Controller 的實作。
在實際開始實作之前,透過測試確認行為以及開發過程中進行驗證都會是個不錯的方式。我們會透過 Cucumber 的文件測試法中的方式,來描述一個運送狀態更新的設計。