要研究DDD，必須認清DDD的核心是通用語言和模型驅動設計。即使是DDDLite（技術上的DDD），也必須清楚DDD在架構中的位置和必須的架構知識，否則一路跑到哪里能否回來都是未知了。我們先了解常用架構分層，再了解DDD的所在層次和范疇，然后強調DDD的核心。包括從架構到領域模型設計方面的決策和自己的些許實踐。
1.三層作為基礎：表示層、業務邏輯層、數據訪問層是所有討論的基礎。
有2個最重要的決策和實踐等待你應用和發現：
（1）在假設存在多個表示層的基礎上，你可以據此將分散在表示層中的業務邏輯代碼從其中分離。
（2）在假設需要支持不同種數據源的的基礎上，你可以將分散在業務邏輯層的數據訪問層代碼從其中分離出來。
這意味着大多數情況你不用冥思苦想、搜腸刮肚的去搞明白到底什么是三層，如果你書讀的多，可以從書中看到這些原則；如果你代碼寫的多又習慣重構你會自然發現這些原則。發現和在重構中應用這些原則是最重要的，完全不可能存在【努力太少，想的太多】的方式搞清這些。
2.四層作為核心：將業務邏輯層分離為應用層和領域層是領域驅動設計的架構方面的核心。
同樣有2個最重要的決策和實踐來保持領域層的純粹：
（1）將表示層必須的業務邏輯調用以應用接口的方式分離到應用層。其他無需公開的部分分離到領域邏輯層。
（2）將業務邏輯對具體技術的依賴轉換為接口依賴，將接口的定義和調用分離到應用層中。
這意味着即使不考慮領域模型的組織形式，我們也可以將應用層和領域層大體上理清。你需要動手，只看是不行的。大多數問題都經不住實踐，重構后大多數問題實際上都不存在，你會總結出這些實踐，但是你的代碼也不會完整的反應出這些原則，那是因為這本身就是架構層次上的決策，沒有任何框架和演示能將架構上決策的東西完美體現出來。完全不可能存在【只看代碼】的方式搞清這些。
3.領域模型的組織形式：實體、值對象和領域服務只是領域模型的一種組織形式。
必須注意2點：
（1）領域模型的組織形式是領域層的范疇。
（2）是否采取經典DDD領域模型的組織方式對架構層次沒有影響。
這里終於到了領域驅動設計相關的概念了，之前討論都是的架構方面的，可以說是無關領域驅動的。領域驅動設計的核心是什么？設計是一個過程，領域驅動是一個原則。在領域驅動的原則下進行設計，設計的結果是一系列主要在領域層范疇的模型。如果自己總結不出來，可以去看經典DDD的附錄領域驅動設計關系圖的人都知道的兩個核心：通用語言和模型驅動設計。因此談論DDD必須要結合具體的領域邏輯和設計中的各種決策以及結果，即使是DDDLite（技術角度的DDD）也不應該因為領域驅動設計中涉及到了很多架構方面的概念就認為這些概念屬於領域驅動設計。至少應該清楚DDD的架構無關性。
4.領域模型的結果：
（1）建模的結果由領域邏輯決定，結果包含一種或多種類型（實體、值對象和領域服務）的一個或多個模型。
（2）如果領域邏輯只是簡單計算過程，那么模型可能只是包含一個方法的一個領域服務。
（3）如果領域邏輯偏向數據管理，模型可能主要由一系列關聯的實體組成，這些實體的形式上和貧血模型一致。
由於大多數的應用程序的領域邏輯都比較簡單，偏向過程和數據操作，因此領域模型顯得不夠豐富，但這都是領域邏輯自然分析得到的結果。在不斷的重構中，實體和領域服務會逐漸的將應用層中的領域邏輯代碼分離出來。
5.實體：
（1）如果業務邏輯用過程表達更適合，實體沒必要存在。
（2）實體對應集合和類型的概念，同種實體的多個對象都是唯一的。因此論壇領域（板塊、主題、評論）和電商領域（分類、產品、訂單）這些都是自然而然的實體類型。
6.值對象：
（1）如果實體比較簡單，值對象沒必要存在。
（2）值對象對於枚舉和狀態的概念。值對象作為實體屬性的一部分。這些值對象本質上是沒有任何差別的。因此論壇領域（主題狀態）和電商領域（交易類型、訂單狀態）這些都是自然而然的值對象。
7.領域服務：
（1）如果實體的方法可以修改為靜態方法，那么這個方法更適合置於領域服務中。
（2）如果我只對領域層進行單元測試，必須反復寫一些出現在應用層的代碼來協調領域邏輯，那么這些代碼很可能屬於領域服務。
8.總結：
（1）在應用DDD之前至少要達到能夠正確的認識三層。如果這點都達不到，不可能成功應用。大體上代碼都不知道寫哪里，還談什么分離領域。
（2）前期必須在架構和建模方面盡量做到層次分明和概念清晰，后期邊重構邊添加功能比不重構添加功能更快，最怕的是認識不上去而不是沒有解決方案。
（3）不是必須掌握所有的DDD知識和概念才能應用DDD。DDD的核心是通用語言和模型驅動設計。
（4）DDD是一個過程，這個過程在不斷的重構中得到最適合的設計和代碼，因此不要為了DDD而DDD。
順便推薦一下ASP.NET設計模式這本書，這本書和作者之前的一些書及其源代碼是這些年國內各大博客論壇的99%的所謂各種框架和原創文章和出版圖書的來源。作者的成功在於類似科普的手法讓大家把模式和代碼直接展示給大家，失敗的是國內萬年不變的抄襲風格依然沒有放過這本書，大把大把二次加工出各種文章、帖子、討論和圖書。但這不是作者和其作品的失敗，而是我們這些披着原創的帽子的抄襲者的悲哀。架構方面的知識，本身必須有多個項目經驗的實踐才能有切實的優缺點體會和認知，DDD更是必須有復雜業務邏輯方面的逐漸重構經驗才能有所積累和體驗。要想有所進步，處處離不開思考和重構。在國內這種技術社區的氣氛下，實踐類的不被推崇，偽技術文（標題黨+圖片黨+程序人生黨）和偽原創（抄襲國外圖書、博客特意聲明為原創的）大行其道，如果你看了好幾年博客覺得沒看到有用的文章，或操作性不強或根本無法推敲，靜下心來，開始閱讀國外的技術書籍和博客，開始重構你的代碼，收獲會日積月累。