重新思考 Rails 架構 系列

我們繼續用「物流系統」作為案例，來探討將軟體架構設計完善時所需的前置準備，也就是去了解整個系統的脈絡（Context）或者說學習該領域（Domain）的知識。

這個過程大多還未進入到開發階段，因此不論語言、框架都是通用的，甚至可以說是否要使用某個語言或者框架，可能要再確認後才決定更加適合。

在領域驅動設計（Domain-Driven Design）中有著上下文邊界（Bounded Context）這樣的概念存在，可以先簡單的理解為協助我們區分不同領域（Domain）的方式。

上下文（Context）我比較喜歡用「脈絡」來描述，當我們已經對脈絡有基本的區分，在對邊界的劃分就會容易很多。

透過釐清脈絡、邊界後，我們大致上就能對整個系統的全貌有一定程度的理解。接下來會需要根據當下系統的狀況，釐清我們需要有哪些類型的物件，以及擔任怎樣的職責，來確保單一職責（Single-responsibility principle）

經過這段時間的分析，我們對於以往在 Rails 開發系統時會遭遇的問題有了近一步理解。接下來，我們要再一次的分析系統的架構，來對原本的設計進行改善。

在實際開始實作之前，透過測試確認行為以及開發過程中進行驗證都會是個不錯的方式。我們會透過 Cucumber 的文件測試法中的方式，來描述一個運送狀態更新的設計。

有了第一個 Cucumber 撰寫的測試後，我們對於更新運送狀態的行為有一定的概念，那麼就可以針對這個機制來進行 Controller 的實作。

實際對運送狀態進行處理之前，我們需要將 Rails 的 ActionController::Parameters 轉換成可以使用的結構，這個結構通常可以看作是 Form Object。

處理完使用者的輸入後，就可以來著手實際的處理。通常會將這些實作放到 app/ 目錄下，然而當我們要以一個 Domain（領域）來劃分時，使用 lib/ 來放置這些實作可能更加恰當，未來要轉換框架或者搬移，就只需要移動 lib/ 而不會和 Rails 綁定。

到 Use Case 階段我們已經初步跟 Rails 框架做出區隔，建構出屬於我們的 Domain Model（領域模型）然而在 Use Case 中含有許多核心概念的處理並沒有被抽離出來，這些東西就是 Entity（實體）也就是整個領域中要處理的對象（Object）

當我們將運送模組（取 module Shipments 的方式稱呼）的實體（Entity）確立下來後，就可以來處理倉庫（Repository）也就是我們的資料如何保存的議題。在某些軟體開發的最佳實踐中，會建議推遲資料庫的設計，就是因為一但確定後就難以修改。

依照這次的流程，我們在接近功能完成時才處理，能省去不少前期就確定資料表結構的問題。