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

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

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

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

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

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

最近因為工作的關係稍微回顧了一下 Open Policy Agent 而發現了 AWS 推出的 Cedar Language 更適合在軟體應用上實現類似 AWS IAM 的 Policy（政策）機制，因為是以 Rust 為基底，為了讓 Ruby 可以使用，就決定嘗試使用 Rust 來撰寫 Extension。

當我們要透過 Ruby on Rails 這個框架來開發這樣的系統時，該如何進行設計呢？大多數時候我們會以模型（Model）為基礎思考，這在 MVC（Model ViewController）框架上還算常見，因為核心邏輯大多會被實作在 Model 上。

在專案初期客戶有提到，第一階段要處理的客戶是最複雜的，只要能夠解決這個客戶的需求，未來就能夠讓客戶服務的其他客戶都能夠使用這套系統。

報表功能也是非常常見的情境，大多數時候我們都會直接使用 Rails 的資料庫內容，搭配 JOIN 類型的查詢進行處理，然而這並不總是個好辦法。

在整個系統的開發過程中，因為客戶的服務是世界性的，因此還需要考慮到時區問題。然而只是單純的時區換算並不會造成問題過於複雜，而是在時區的呈現上並不像我們平常理解的那樣。

現代大部分的軟體都會考慮到使用者體驗（User Experience）因此都會盡量設計成簡單易懂的操作，然而仍有一些例外的狀況，像是有高度專業需求的系統，或者一些傳統產業長久以來的習慣，當時客戶就屬於這一類型。