分佈式設計模式-（領域驅動模型）DDD

DDD（Domain-Driven Design 領域驅動設計）是由Eric Evans最早提出，目的是對軟件所涉及到的領域進行建模，以應對系統規模過大時引發的軟件複雜性的問題。整個過程大概是這樣的，開發團隊和領域專家一塊兒經過 通用語言(Ubiquitous Language)去理解和消化領域知識，從領域知識中提取和劃分爲一個一個的子領域（核心子域，通用子域，支撐子域），並在子領域上創建模型，再重複以上步驟，這樣周而復始，構建出一套符合當前領域的模型。

這裏須要注意幾點：

• 通用語言是一個很泛的概念，它做爲一種溝通工具，在開發團隊內部，開發團隊與領域專家之間使用。它包含了天然語言、文檔和圖表（不必定是標準的UML圖，只要能表達出領域知識的均可以）等內容。對通用語言中名詞，動詞的使用須要認真考量，由於這些名詞和動詞會做爲後面模型的指導命名。
• 通用語言中定義的術語在一個 限界上下文(bounded context)中不能存在二義性。同一個事物在不一樣的限界上下文中由於所關注的側重點不一樣，因此所表達出的概念是不一樣的，但在同一個限界上下文中應該表示的是一個概念。好比用戶在微信中的聊天場景，朋友圈以及支付場景中全部表達的概念就應該是不一樣的，聊天場景關注的是用戶間的聊天內容，而支付場景關注的是用戶的帳戶餘額。 一個子域能夠包含多個限界上下文。
• 模型（Entity，值對象，Service，Aggregate root）是存在於限界上下文中的。

分層架構

DDD中將系統分爲UI層，應用層，領域層以及基礎設施層。

上圖中，應用層是很薄的一層，由於它只負責接收UI層傳來的參數和路由到對應的領域模型，它不負責處理具體的業務邏輯。系統的業務邏輯放在了領域層中，因此，領域層在系統架構中佔據了很大的面積。 在層級結構中，上層模塊調用下層模塊提供的服務，這裏就會存在一種依賴關係，Rebort C. Martin提出的依賴倒置原則大體是以下：

上層模塊不該該依賴於下層模塊，二者都應該依賴於抽象；
抽象不該該依賴於實現，實現應該依賴於抽象;
複製代碼

DDD元素

在使用DDD設計系統時，主要包括Entity，Value Object，Service,Aggregate,Repository,Factory,Domain Event,Moudle等元素

在建模時，Entity能夠用來表明一個事物。既然Entity是用來表明一個事物的，那麼它就應該有一個惟一值來標識這個事物，同時，他還能記錄這個事物狀態的變化。好比：Id爲5的Person對象，它的名字是張三，過兩天，他將本身的名字改成李四。可是，這我的（Id=5）仍是這我的（Id=5），只是他名字的狀態以及發生了變化，而這個變化後的狀態被Person這個Entity記錄了下來。 Value Object是用來描述事物的某一方面的特徵，因此它是一個無狀態的，且是一個沒有標識符的對象，這是和Entity的本質區別。拿訂單來講，一張訂單在系統中應該有一個惟一的標識，且具備狀態，因此訂單是一個Entity對象，而這張訂單共￥100元，則是描述了這個訂單的總額特徵，￥100元能夠用值對象表示爲{100，￥}，及金額和幣種的組合。{100，￥}在任何限界上下文中都描述的是￥100元，是由於他們比較的是裏面的內容（金額和幣種），而上面的張三在修了名後，仍是原來的那我的，是由於它比較的是惟一標示ID的值。 Aggregate是一組相關對象的集合，它做爲數據修改的基本單元，爲數據修改提供了一個邊界。每一個聚合都有一個根和一個邊界，根也是一個實體，聚合邊界之外的對象只能經過根對聚合內部元素操做。聚合將一組相關的對象內聚到一塊兒，從而將系統的複雜程度下降。 repository用來存儲聚合，至關於每個聚合都應該有一個倉庫實例。Entity和Value Object都應該具備行爲，而有些行爲從語義上講，不適合放到這兩個對象中，因此就單獨抽象了一個Service對象，用來存放這些行爲。Factory是用來生成聚合的，當生成一個聚合的步驟過於複雜時，能夠將其生成過程放在工廠中。