軟體架構的挑戰 - 重新思考 Rails 架構
約 2010 年左右,我開始接觸到許多程式語言的社群、研討會,因此大量吸收許多軟體開發的知識。當時,在業界中一個很常被提到的職稱「架構師」對當時還是學生的自己似乎有點遙遠。而我直到十多年後,才意識到「架構」的意義。
Pager 1
約 2010 年左右,我開始接觸到許多程式語言的社群、研討會,因此大量吸收許多軟體開發的知識。當時,在業界中一個很常被提到的職稱「架構師」對當時還是學生的自己似乎有點遙遠。而我直到十多年後,才意識到「架構」的意義。
當時收到新客戶的需求時,表示是一套很老舊的系統無法維護,急需開發一套新系統來維持業務的運作。客戶自己的工程師已經忙不過來,因此找到我當時任職的公司協助開發這套新系統,並且表示他們已經分析完畢,只需要依照 ERD(Entity-Relationship Diagram)實作即可。
現代大部分的軟體都會考慮到使用者體驗(User Experience)因此都會盡量設計成簡單易懂的操作,然而仍有一些例外的狀況,像是有高度專業需求的系統,或者一些傳統產業長久以來的習慣,當時客戶就屬於這一類型。
在整個系統的開發過程中,因為客戶的服務是世界性的,因此還需要考慮到時區問題。然而只是單純的時區換算並不會造成問題過於複雜,而是在時區的呈現上並不像我們平常理解的那樣。
報表功能也是非常常見的情境,大多數時候我們都會直接使用 Rails 的資料庫內容,搭配 JOIN 類型的查詢進行處理,然而這並不總是個好辦法。
在專案初期客戶有提到,第一階段要處理的客戶是最複雜的,只要能夠解決這個客戶的需求,未來就能夠讓客戶服務的其他客戶都能夠使用這套系統。
當我們要透過 Ruby on Rails 這個框架來開發這樣的系統時,該如何進行設計呢?大多數時候我們會以模型(Model)為基礎思考,這在 MVC(Model ViewController)框架上還算常見,因為核心邏輯大多會被實作在 Model 上。
在 Rails 中除了以模型(Model)為出發點思考如何設計,我們也可以從領域(Domain)的角度進行思考,雖然 Rails 的架構對於領域驅動設計(Domain-Driven Design)的應用一直都是社群想挑戰的主題,仍沒有主流的方式,然而從不同的角度思考仍是有助於設計更好的系統。
不論是資料驅動(Data-Driven)還是領域驅動(Domain-Driven)的角度,思考的範圍仍侷限在單一功能,如果要討論一個完整系統,就需要再繼續往上提升層級到架構(Architecture)的角度進行思考。
架構問題對於完整的領域驅動設計(Domain-Driven Design)仍屬於戰術(Tactical)問題,也就是開始實踐的部分,還需要再往上思考策略(Strategic)問題,關於軟體的目的的思考。
在學習軟體開發的過程中,很常會看到重用(Reuse)這樣的概念,或者說我們會試著讓一段程式碼可以在許多地方被呼叫跟使用。這也跟我們將程式碼歸類成特定類型的物件、或者一系列的方法模組的開發方式有關,這件事情似乎是非常自然的。