1.DDD架構的概念:
領域驅動設計(Domain-Driven Design, DDD)是一種軟件設計方法,旨在將軟件系統的設計和開發焦點集中在領域模型上,以解決復雜業務問題
2.DDD架構解決了什么問題:
在以前的mvc架構種,三層結構,簡單明了。但是當項目越來越大,維護的時間久了的話,就會出現問題,各種PO,VO,DTO對象越來越多,并且會出現多個接口調用同一個VO對象
會導致實體類越來膨脹,時間久了實體類的定義越來越模糊。就變成了一屎山代碼。
而DDD是讓各個模塊盡可能的都在自己的領域包中。那樣會盡可能的減少PO VO的調用,相當于在MVC的基礎,將實體類的貧血模型,改成了充血模型。
3.DDD架構各個模塊
xfg-frame-api 接口定義
其實該module更多做的是為xfg-frame-trigger提供定義好的RPC接口,但是不僅僅只有這些,還有像HTTP接口,MQ接口,甚至TASK接口都可以在xfg-frame-api中定義好,
因為xfg-frame-trigger引用了xfg-frame-api,所以會直接impl即可
xfg-frame-app 應用封裝
該module在我看來是應用啟動和配置這一層的,比如你可以設置一些基本的配置,如AOP配置,線程池配置,數據庫連接池配置等,通過整個項目的配置文件也在此處,包括 mybatis.xml 和 application.yaml等配置。這個類可以說是非常的重要,打包鏡像就是在這一層,該module引入了xfg-frame-trigger 觸發調用 和 xfg-frame-infrastructure 基礎設施,也就是說將來在打包的時候,它可以被理解為專門為了啟動服務而存在的
xfg-frame-domain 領域封裝
領域模型服務,是一個非常重要的模塊,無論怎么做DDD的分層架構,domain肯定是要存在的,那么在這一層中就要一個個的細分領域模型,也就是包含每個領域模型都要有的三大要素:“模型 倉庫 服務”。
xfg-frame-infrastructure 基礎設施|
這個層是依賴于domain領域層的,因為在domain層定義了倉庫接口 需要在基礎層實現,這是一個依賴倒置的一種設計思路。
前面說到了,在基礎層實現了domain領域的接口,實現了其對應的接口的功能,而 xfg-frame-trigger中也引用了domain,那么通過多態,實際上,那么trigger中引入的domain里的倉庫方法實際上由infrastructure 實現了
xfg-frame-trigger 觸發調用
該層相對好理解,主要用于提供接口實現,消息接收,任務執行等,相當于觸發器層,主要引入了 domain api 和 types
xfg-frame-types 類型定義
主要是作為通用類型定義層,在我們的系統開發中,會有很多類型的定義,包括基本的Response,Contants和枚舉。它們會被其他層引用。
4.領域分層
這個地方是我認為DDD的核心部分了,也就是domain部分,前面其實還是較少介紹的,只說了其包含三個部分“模型 倉庫 服務” 但是實際上包含著更多的內容,
如下圖所示:
值對象:表示沒有唯一標識的業務實體,例如商品的名稱、描述、價格等。
實體對象:表示具有唯一標識的業務實體,例如訂單、商品、用戶等;
聚合對象:是一組相關的實體對象的根,用于保證實體對象之間的一致性和完整性;
4.1依賴倒置原則
依賴倒置原則的原始定義為:高層模塊不應該依賴低層模塊,兩者都應該依賴其抽象;抽象不應該依賴細節,細節應該依賴抽象。其核心思想是:要面向接口編程,不要面向實現編程。依賴倒置原則是實現開閉原則的重要途徑之一,它降低了客戶與實現模塊之間的耦合
理解:高層模塊不應該直接調用底層模塊的具體實現,應該調用底層模塊的抽象,這樣當底層模塊進行修改的時候不會影響高層模塊。
4.2開閉原則
開閉原則(Open Closed Principle, OCP)是面向對象設計的基本原則之一,它要求軟件實體(如模塊、類、方法等)應當對擴展開放,對修改關閉。這意味著當軟件的需求發生變化時,我們不需要修改原有的代碼,而是通過擴展的方式來滿足新的需求。
對擴展開放:允許在不修改現有代碼的情況下增加新的功能或行為。
對修改關閉:限制對現有代碼的修改,以減少代碼的耦合性和提高系統的可維護性。
實現開閉原則的方法包括:
抽象約束,封裝變化:通過接口或抽象類定義一個相對穩定的抽象層,而將可變的部分封裝在具體實現類中。這樣,當軟件需要變化時,只需要添加新的實現類來擴展功能,而不需要修改原有的代碼。
依賴抽象而非具體實現:通過依賴抽象類或接口而不是具體實現類來編程,可以提高代碼的可復用性和可維護性。
使用設計模式:如策略模式、模板方法模式等,這些模式可以幫助我們更好地遵循開閉原則,實現代碼的靈活性和可擴展性。
5.MVC分層架構
分層架構是典型的架構例子,該架構將元素按照“層”的方式組織,每個層有定義明確的職責,同時限制了層與層之間的依賴關系。即:每一層只能依賴于緊鄰的下層或下面的任何層。以常見的三層架構為例(三層架構是應用于邏輯視圖的分層架構),三層架構將應用程序的類組織展示如圖2.1所示:
在實際開發過程中,三層架構隨著業務的逐漸龐大會出現很明顯的弊端,比如,在表示層中有邏輯層的代碼,導致在實際的三層架構模型中,下層會依賴上層,違背了三層分層機構只能上層依賴下層的原則,導致分層邊界越來越模糊。