從戰略入門
這種方式相對比第一種方法，費時很多，需要很大的毅力堅持，但因為是在實踐中不斷成長的，最終是可以形成自己的方法論的。但耗時太慢長，我自己不斷實踐落地 DDD 近 5 年，才形成了自己一丢丢的方法論。
接下來給大家提供一些總結的資料，供大家入門學習：
- 實體、聚合、值對象、聚合、工廠、倉儲、領域服務等領域模型的基礎概念，盡量白話準确；
- 提供了挖掘通用語言的兩種方法，指導如何從需求文章中快速的挖掘通用語言；
- 提供一個領域模型圖 Demo，大家可以選取自己工作中最熟悉的業務，畫一畫；
- 選取了兩個角度，描述下如何寫出業務高内聚的 DDD 代碼。
大家可以按照 1、2、3、4 的步驟來試一試，這個學習路徑，最關鍵的點在于敢于實戰，在失敗中總結經驗，如果你隻是看看、不動手，不敢于失敗很多次的話，建議還是學習第一種方法吧。
實體
實體是具有唯一辨別的，可以表示業務連續性變化的領域元素。
唯一辨別很好了解，就像人的身份證一樣，不管人的年齡如何變化，住宅位址如何變化，你的身份證都是不變的，唯一辨別一直能夠在實體變化過程中辨識實體。
業務連續性變化的了解，我們拆分成兩個：
- 如何知道業務發生了變化
- 業務連續性變化
如何知道業務發生了變化：如果目前業務變化已經導緻實體的屬性發生變化，那麼目前業務就已經發生變化了。
我們舉個例子：比如你在淘寶買東西，下單之後會生成一個訂單實體，在之後的任意時刻，隻要訂單實體的屬性發生了變動，就表明目前訂單業務發生了變化。
比如訂單實體有個屬性，叫做訂單狀态，訂單剛生成的時候，是支付成功待發貨狀态，然後商家操作了發貨，訂單的狀态就會變成已發貨，那麼此時訂單的狀态從待發貨變成了已發貨，訂單的屬性發生了變化，即業務發生了變化。
業務連續性變化：實體屬性的變化在時間上有跨度，我們稱為業務有連續性變化。
比如說訂單狀态從已發貨，又變更成了訂單完成，這裡訂單狀态的變化，在時間上是有一定的跨度的，就是說目前業務有連續性的變化。
以上兩種說明是為了讓大家更好的了解，隻針對實體而言，因為業務這個詞的範疇太大了，很難定義業務是什麼，但在實體的範疇内，業務的變化可以直接展現在實體屬性的變化上。
值對象
定義：值對象是對事物的描述，更确切的說，就是對領域對象的描述。
比如說下單場景中，我們會記錄下單的來源資訊，比如說訂單是 H5 下單，還是 App 下單？下單的 IP 位址是多少？下單的手機型号又是什麼？這些來源資訊就是對訂單實體的一種描述，我們可以叫做值對象。
既然是對實體的一種描述，那麼描述一旦産生，大多數情況下都是已經發生了的事情，就是死的，不會在更改了，這也是值對象的一大特性。
聚合
把領域對象聚合在一起，并維護領域對象之間的關系，我在一篇免費文章上詳細地說過，說的很明白，連結：
https://dwz.cn/XZ9HCMqy
工廠
工廠比較簡單，主要是用來幹兩件事情，建立對象和重塑對象。 當實體、聚合、值對象的建立邏輯比較複雜的時候，我們就可以使用工廠進行建立。
重塑對象的例子：
我們在和外部公司進行對接的時候，大多數會通過 HTTPS 接口進行遠端調用，這時我們接受到傳回的參數，很可能是個 JSON 格式，因為依賴不了外部公司的 API 包，JSON 就不能反序列化成一個 DTO，這時候 JSON 轉化成可使用的對象就比較複雜。我們可以把複雜的轉化工作交給工廠，工廠此時的作用就是把 JSON 格式轉化成可直接使用的對象。這種場景在對接基金保險公司時特别常見，基金保險公司的外部接口往往很複雜，字段非常多，這時候轉化工作就很繁瑣，利用工廠進行轉化會很合适。
倉儲
Repository 是用來做對象的儲存和通路的，作用是讓大家始終聚焦領域模型。
對象的存儲和通路大家應該都清楚，就是增删改查，這個大家都會，這個也不是倉儲的重點。
倉儲的重點在于如何讓大家始終聚焦領域模型，在實際工作中，大家寫代碼的時候，都是一張表一個倉儲，這是不對的，倉庫的定義應該從業務出發，而不應該去适配表結構。
領域服務
領域服務是一個動作，當動作挂不到領域對象上時（動作不是領域能力的時候），我們就把它叫做領域服務。
以上就是 DDD 領域層常見的領域元素，然後我又畫了一張落地思路圖：
這位同學也時常和我溝通，突然有一天，丢了一個領域模型圖給我，我看了下，覺得畫的很好，算是戰略入門了，從這個同學身上我還發現另外一種特質：敢于動手。
很多同學學習 DDD 絲毫不敢動手，或者說懶于動手，懶得整理通用語言，懶得畫領域模型圖，隻靠眼睛看，看是永遠都學不會 DDD，也落地不了 DDD 的。
領域模型
領域模型對業務的一種抽象，領域模型圖就是業務的抽象表達，好的領域模型圖往往能讓你事半功倍，提供一個領域模型圖模版給大家：
這個領域模型圖用不同形狀 + 不同顔色，代表了 6 種領域元素，用不同箭頭形狀代表了領域元素之間的邏輯關系，在我們實際工作中已經夠用了，領域模型圖大家能看懂就行，易懂的同時在加上好看那就更好了，至今為止，沒有見過比這個好看易懂的領域模型圖了。
那麼領域模型圖來自何處呢？來自通用語言。
在畫領域模型圖之前，我們必須要把通用語言整理出來，然後再把通用語言轉化成領域模型圖，在通用語言轉化領域模型的過程中，應該根據領域元素的定義來進行劃分，完全可以一一對應。
如何挖掘通用語言？
首先大家要清楚什麼是通用語言。
通用語言的基礎定義：一定上下文内，對業務概念的一緻通用表達。直白來說，就是團隊内部成員，在同一個上下文内，對同一個業務概念的了解是一緻的。
但很多人往往看不到通用語言的深層含義：理清業務是什麼，能幹什麼，以及和其他業務邊界的過程。
在領域模組化時，最重要的就是通用語言的梳理了，一般我會花一半的時間放到通用語言的建立上，在整理通用語言的過程中，我們會去想很多：領域的定義？領域的能力？領域的邊界？……
挖掘通用語言我自己有兩種辦法：
- 抓住名詞，聯想動詞：這種辦法特别簡單，可以快速幫助我們把需求場景想全。
- WR 原則：在九十年代的時候，有人提出了 5W1H 分析法，來幫助人們快速地了解問題和解決問題，其目标是為了快速地弄明白問題。下圖就是 5W1H 分析法的圖解：
截圖來自百度百科。5W1H 法展現了一種分析過程，但落地的時候，這種過程不重要，分析的結果卻特别重要。比如說你在淘寶下單，得到訂單；發貨，得到發貨單；退款，得到退款單，你可以用 5W1H 分析下單、發貨和退款的過程，但領域模組化時，你關注的卻是訂單、發貨單和退款單三種結果，是以說分析的結果特别重要，我們在 5W1H 的基礎上加了一個結果 Result，簡讀就是 WR 原則。