概述
DDD（Domain-Driven Design 領域驅動設計）是由Eric Evans最先提出，目的是對軟件所涉及到的領域進行建模，以應對系統規模過大時引起的軟件複雜性的問題。整個過程大概是這樣的，開發團隊和領域專家一起通過 通用語言(Ubiquitous Language)去理解和消化領域知識，從領域知識中提取和劃分爲一個一個的子領域（核心子域，通用子域，支撐子域），並在子領域上建立模型，再重複以上步驟，這樣周而復始，構建出一套符合當前領域的模型。
DDD概述
這裏需要注意幾點：
- 通用語言是一個很泛的概念，它作爲一種溝通工具，在開發團隊內部，開發團隊與領域專家之間使用。它包含了自然語言、文檔和圖表（不一定是標準的UML圖，只要能表達出領域知識的都可以）等內容。對通用語言中名詞，動詞的使用需要認真考量，因爲這些名詞和動詞會作爲後面模型的指導命名。
- 通用語言中定義的術語在一個 限界上下文(bounded context)中不能存在二義性。同一個事物在不同的限界上下文中因爲所關注的側重點不同，所以所表達出的概念是不同的，但在同一個限界上下文中應該表示的是一個概念。比如用戶在微信中的聊天場景，朋友圈以及支付場景中所有表達的概念就應該是不同的，聊天場景關注的是用戶間的聊天內容，而支付場景關注的是用戶的賬戶餘額。
- 一個子域可以包含多個限界上下文。
- 模型（Entity，值對象，Service，Aggregate root）是存在於限界上下文中的。
分層架構
DDD中將系統分爲UI層，應用層，領域層以及基礎設施層。
分層架構
上圖中，應用層是很薄的一層，因爲它只負責接收UI層傳來的參數和路由到對應的領域模型，它不負責處理具體的業務邏輯。系統的業務邏輯放在了領域層中，所以，領域層在系統架構中佔據了很大的面積。
在層級結構中，上層模塊調用下層模塊提供的服務，這裏就會存在一種依賴關係，Rebort C. Martin提出的依賴倒置原則大致是如下：
上層模塊不應該依賴於下層模塊，兩者都應該依賴於抽象；
抽象不應該依賴於實現，實現應該依賴於抽象;
這是一個面向接口編程的思想，抽象說的是抽象類或接口，實現就是具體實現了這些抽象的實現類。翻譯成白話文是這樣的，上下層之間應該通過接口來通訊，接口定義的位置就決定了上下層的依賴關係是否倒置。比如Application層和Domain層進行通訊，接口與接口的實現類都定義在Domain層中，這是正常的面向接口編程，不存在倒置關係。而Domain層和基礎設施層進行通訊時，原本是Domain層去依賴基礎設施層，如果我們將接口定義在Domain層，而實現類定義在基礎設施層，那麼，基礎設施層就將依賴Domain層，這就是“倒置”這個詞的來由。實際上，我們在做這樣分層架構設計時，都是將接口定義在Domain層的。
DDD元素
在使用DDD設計系統時，主要包括Entity，Value Object，Service,Aggregate,Repository,Factory,Domain Event,Moudle等元素。
ddd元素
在建模時，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是用來生成聚合的，當生成一個聚合的步驟過於複雜時，可以將其生成過程放在工廠中。