參考：https://insights.thoughtworks.cn/backend-development-ddd/

　　戰略設計： 更偏向於軟體架構，得到限界上下文，拆分成多個微服務。

　　戰術設計： 更偏向於編碼實現。DDD戰術設計的目的是使得業務能夠從技術中分離並突顯出來，讓程式碼直接表達業務的本身，其中包含了聚合根、應用服務、資源庫、工廠等概念。通常會應用設計模式。

關鍵原則：

　　聚合根的實現應該與框架無關：既然DDD講求業務複雜度和技術複雜度的分離，那麼作為業務主要載體的聚合根應該儘量少地引用技術框架級別的設施，最好是POJO

聚合根之間的引用通過ID完成：

　　聚合根內部的所有變更都必須通過聚合根完成

　　如果一個事務需要更新多個聚合根，首先思考一下自己的聚合根邊界處理是否出了問題，因為在設計合理的情況下通常不會出現一個事務更新多個聚合根的場景。如果這種情況的確是業務所需，那麼考慮引入訊息機制和事件驅動架構，保證一個事務只更新一個聚合根，然後通過訊息機制非同步更新其他聚合根。

　　聚合根不應該引用基礎設施。

　　外界不應該持有聚合根內部的資料結構。

　　儘量使用小聚合。

下圖說明：不同的限界上下文，都可以有Product物件；

實體VS 值物件：

　　實體： 實體物件表示的是具有一定生命週期並且擁有全域性唯一標識(ID)的物件，比如本文中的Order

　　值物件：表示用於起描述性作用的，沒有唯一標識的物件，比如Address物件。

　　區分實體和值物件的一個很重要的原則便是根據相等性來判斷

　　　　實體物件的相等性是通過ID來完成的，對於兩個實體，如果他們的所有屬性均相同，但是ID不同，那麼他們依然兩個不同的實體，就像一對長得一模一樣的雙胞胎，他們依然是兩個不同的自然人。

　　　　值物件相等性的判斷是通過屬性欄位來完成的。

資源庫(Repository)就是用來持久化聚合根的

　　不過DAO的設計初衷只是對資料庫的一層很薄的封裝，而Repository是更偏向於領域模型。另外，在所有的領域物件中，只有聚合根才“配得上”擁有Repository