DDD(Domain-Driven Design 領域驅動設計)是由Eric Evans最早提出,目的是對軟件所涉及到的領域進行建模,以應對系統規模過大時引發的軟件複雜性的問題。整個過程大概是這樣的,開發團隊和領域專家一塊兒經過 通用語言(Ubiquitous Language)去理解和消化領域知識,從領域知識中提取和劃分爲一個一個的子領域(核心子域,通用子域,支撐子域),並在子領域上創建模型,再重複以上步驟,這樣周而復始,構建出一套符合當前領域的模型。編程
這裏須要注意幾點:微信
DDD中將系統分爲UI層,應用層,領域層以及基礎設施層。架構
上圖中,應用層是很薄的一層,由於它只負責接收UI層傳來的參數和路由到對應的領域模型,它不負責處理具體的業務邏輯。系統的業務邏輯放在了領域層中,因此,領域層在系統架構中佔據了很大的面積。工具
在層級結構中,上層模塊調用下層模塊提供的服務,這裏就會存在一種依賴關係,Rebort C. Martin提出的依賴倒置原則大體是以下:ui
上層模塊不該該依賴於下層模塊,二者都應該依賴於抽象;
抽象不該該依賴於實現,實現應該依賴於抽象;架構設計
這是一個面向接口編程的思想,抽象說的是抽象類或接口,實現就是具體實現了這些抽象的實現類。翻譯成白話文是這樣的,上下層之間應該經過接口來通信,接口定義的位置就決定了上下層的依賴關係是否倒置。好比Application層和Domain層進行通信,接口與接口的實現類都定義在Domain層中,這是正常的面向接口編程,不存在倒置關係。而Domain層和基礎設施層進行通信時,本來是Domain層去依賴基礎設施層,若是咱們將接口定義在Domain層,而實現類定義在基礎設施層,那麼,基礎設施層就將依賴Domain層,這就是「倒置」這個詞的來由。實際上,咱們在作這樣分層架構設計時,都是將接口定義在Domain層的。翻譯
在使用DDD設計系統時,主要包括Entity,Value Object,Service,Aggregate,Repository,Factory,Domain Event,Moudle等元素。設計
在建模時,Entity能夠用來表明一個事物。既然Entity是用來表明一個事物的,那麼它就應該有一個惟一值來標識這個事物,同時,他還能記錄這個事物狀態的變化。好比:Id爲5的Person對象,它的名字是張三,過兩天,他將本身的名字改成李四。可是,這我的(Id=5)仍是這我的(Id=5),只是他名字的狀態以及發生了變化,而這個變化後的狀態被Person這個Entity記錄了下來。orm
Value Object是用來描述事物的某一方面的特徵,因此它是一個無狀態的,且是一個沒有標識符的對象,這是和Entity的本質區別。拿訂單來講,一張訂單在系統中應該有一個惟一的標識,且具備狀態,因此訂單是一個Entity對象,而這張訂單共¥100元,則是描述了這個訂單的總額特徵,¥100元能夠用值對象表示爲{100,¥},及金額和幣種的組合。{100,¥}在任何限界上下文中都描述的是¥100元,是由於他們比較的是裏面的內容(金額和幣種),而上面的張三在修了名後,仍是原來的那我的,是由於它比較的是惟一標示ID的值。對象
Aggregate是一組相關對象的集合,它做爲數據修改的基本單元,爲數據修改提供了一個邊界。每一個聚合都有一個根和一個邊界,根也是一個實體,聚合邊界之外的對象只能經過根對聚合內部元素操做。聚合將一組相關的對象內聚到一塊兒,從而將系統的複雜程度下降。
repository用來存儲聚合,至關於每個聚合都應該有一個倉庫實例。Entity和Value Object都應該具備行爲,而有些行爲從語義上講,不適合放到這兩個對象中,因此就單獨抽象了一個Service對象,用來存放這些行爲。Factory是用來生成聚合的,當生成一個聚合的步驟過於複雜時,能夠將其生成過程放在工廠中。