DDD 極簡入門教程
概述
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都應該具有行為，而有些行為從語義上講，又放到這兩個物件中，所以就單獨抽象了一個服務物件，用來存放這些行為。Factory是用來生成聚合的，當生成一個聚合的步驟過於複雜時，可以將其生成過程放在工廠中。