架構規劃 - 重新思考 Rails 架構
經過這段時間的分析,我們對於以往在 Rails 開發系統時會遭遇的問題有了近一步理解。接下來,我們要再一次的分析系統的架構,來對原本的設計進行改善。
經過這段時間的分析,我們對於以往在 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)的應用一直都是社群想挑戰的主題,仍沒有主流的方式,然而從不同的角度思考仍是有助於設計更好的系統。
最近因為工作的關係稍微回顧了一下 Open Policy Agent 而發現了 AWS 推出的 Cedar Language 更適合在軟體應用上實現類似 AWS IAM 的 Policy(政策)機制,因為是以 Rust 為基底,為了讓 Ruby 可以使用,就決定嘗試使用 Rust 來撰寫 Extension。
當我們要透過 Ruby on Rails 這個框架來開發這樣的系統時,該如何進行設計呢?大多數時候我們會以模型(Model)為基礎思考,這在 MVC(Model ViewController)框架上還算常見,因為核心邏輯大多會被實作在 Model 上。