關於 #Rails 的內容

今年 RubyKaigi 2026 時，剛好在跟朋友聊 Harness Engineering 提到 Sandbox 的部分，覺得 Ruby 語言目前還沒有比較完善的解決方案，剛好第二天晚上的 Code Party 被分配到 druby（Ruby 語言內建的分散式系統）組別，讓我有了靈感，讓 Kobako 被設計出來。

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

前面我們主要著重在寫入的處理，如果是單純寫入的處理，我們可以使用 Query 來處理。基本上 Command 和 Query 都可以看作 Use Case（使用案例）的一種，可以根據複雜程度決定是否需要細分，當我們實踐到這個階段，也接近有讀寫分離的系統所呈現的狀態。

在 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 的文件測試法中的方式，來描述一個運送狀態更新的設計。