領域驅動設計(DDD) - 分層設計與 ASP.NET 專案

此系列為圖書《商業級 ASP.NET MVC 樣式與架構實務》延伸閱讀教學文章
歡迎搭配圖書閱讀,提升商業應用開發能力

領域驅動設計理論最重要的核心工作,在於轉換領域問題形成對應的模型,這是塑模的過程,然後再由開發人員著手撰寫程式碼進行模型的實作,除了模型本身必須精確的反映領域的核心概念,實作的程式碼則需要能夠正確的呈現出模型所要反映的概念。

開發軟體的過程中,我們透過幾個階段的設計過程,支援領域驅動設計理論的實踐。

分層架構

完整的應用程式除了用來表示領域的模型設計,通常還包含其它用以建構應用程式的功能,這些部份並沒有直接關聯至領域本身,例如基礎架構、串接工作流程的應用程式介面、資料庫、檔案或是網路資源的存取等等,當我們沒有明確的將涉領域核心概念的程式碼分離出來,一旦商業邏輯發生改變,勢必會牽動其它非相關程式碼,導致領域驅動設計實踐的困難,因此我們必須嘗試將領域相關的程式碼從其它的程式碼中分離出來,並保持簡化,單純的反映領域概念,除了有助於理解領域問題,同時容易貼近商業邏輯進行設計。

為了明確分離領域相關的程式碼,我們需要為應用程式導入分層架構設計,領域驅動設計理論,以四個概念定義分層架構:


如圖列舉說明,各概念層負責專屬功能實踐,並且透過逐層互動實踐商業流程。

應用程式開發的過程中,相關的能凝聚於獨立的概念層,層與層之間,利用介面隔離以及相依性注入的設計,建立鬆散耦合的關係,以表列的順序為依據,每一個分層原則上僅會往下層引用,而領域層則獨立支援模型定義,專注在領域模型的核心概念描述,也是反映商業邏輯的主要概念層,提供其它概念層所需的模型物件實體參考。

ASP.NET MVC 的分層實作

一般小型應用程式,利用Visual Studio 建立的單一專案即可處理,典型的專案依據 MVC樣式,將應用程式的內容,切割至Models、Views以及Controllers資料夾,其中Models負責資料模型與存取,而Views的任務是呈現與格式化輸出資料,Controllers 則是負責接收要求與回應。

ASP.NET MVC的設計在邏輯上遵循 MVC樣式,但這僅是慣例,開發人員可以根據自己的理解與需求,設計每個部份的功能,甚至不需考慮邏輯上的合理性,但是如此一來將會導致應用程式未來發展的困難。

將商業邏輯配置於Controllers是常見的作法,這讓控制器在其處理要求與回應的核心功能中,增加了額外的負擔,除了讓控制器變得肥大不易管理,邏輯程式碼的重用亦變得困難,最重要的,當商業邏輯發生改變時,將進一步導致控制器的維護付出昂貴的異動成本。
對於稍具規模的應用程式,考慮另外建立商業邏輯層,封裝商業服務,控制器將重心放在處理要求與回應作業,在需要的時候直接取用商業服務,調度應用程式的執行流程。


上圖的架構,另外建立一個提供商業服務的邏輯層,而為了讓應用程式的維護與開發更為彈性,更進一步的,針對其中Models的部份,我們可以再作拆分,將連接底層資料來源的程式碼,拆解至存取庫(Repository),其中涵蓋所有與底層資料來源存取有關的功能物件。


現在我們有比較的清楚的概念,為ASP.NET MVC導入明確的分層,建立專屬資料夾來完成相關的實作,以命名空間實現概念層設計,而對於更複雜的大型專案,可以考慮進一步建立獨立的專案以支援更彈性的設計。

持續討論更複雜的設計之前,我們透過一些實作來說明實際的分層設計。





沒有留言: