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

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

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

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

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

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

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

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

這個問題我個人目前還沒有一個邏輯足夠完整的答案，然而最近思考後認為蠻適合拋出來討論。

會回過頭來思考這個問題，也是因為對 Clean Architecture 的使用足夠熟練，要開始準備來深入了解經常一起應用的 Domain-Driven Design，那就一定會遇到這個問題。

在學習軟體開發的過程中，很常會看到重用（Reuse）這樣的概念，或者說我們會試著讓一段程式碼可以在許多地方被呼叫跟使用。這也跟我們將程式碼歸類成特定類型的物件、或者一系列的方法模組的開發方式有關，這件事情似乎是非常自然的。

不論是資料驅動（Data-Driven）還是領域驅動（Domain-Driven）的角度，思考的範圍仍侷限在單一功能，如果要討論一個完整系統，就需要再繼續往上提升層級到架構（Architecture）的角度進行思考。

架構問題對於完整的領域驅動設計（Domain-Driven Design）仍屬於戰術（Tactical）問題，也就是開始實踐的部分，還需要再往上思考策略（Strategic）問題，關於軟體的目的的思考。

在 Rails 中除了以模型（Model）為出發點思考如何設計，我們也可以從領域（Domain）的角度進行思考，雖然 Rails 的架構對於領域驅動設計（Domain-Driven Design）的應用一直都是社群想挑戰的主題，仍沒有主流的方式，然而從不同的角度思考仍是有助於設計更好的系統。