什麼是你的領域模型？
從技術角度來看，我認為DDD專案只不過是劃定一個清晰且受保護的領域。雖然我在處理大量遺留程式碼，但我發現常見的DDD錯誤是無法準確識別領域內的內容以及外部的內容。
您的資料模型不是您的域模型
將資料模型用作領域模型是一個非常常見的錯誤。我認為 ping" rel="nofollow,noindex" target="_blank">ORM 和 CRUD 對這種誤解負有部分責任。資料模型是針對資料儲存優化的模型的表示。
使用ORM構建的模型物件不會使其成為領域模型。它仍然是一種資料模型，它仍然針對資料儲存進行了優化。它只是不再是sql表，僅此而已。
資料模型負責儲存資料，而域模型負責處理業務邏輯。只有在資料模型周圍沒有業務邏輯時，才能將應用程式視為CRUD。即使在這種（罕見）情況下，您的資料模型也不是您的域模型。它只是意味著，由於不涉及業務邏輯，我們不需要任何抽象來管理它，因此我們沒有領域模型。
您的檢視模型不是您的域模型
另一個常見錯誤是在資料模型和檢視之間只新增一個層。這個層在不同的模式和語言中有不同的名稱（Presenter，Controller，ViewModel ...... 等各種MVC中P/C/VM），但想法是一樣的：使用程式碼抽象檢視。
錯誤是我們認為這是新增業務邏輯的地方。但是這些層已經有負責抽象檢視，我們不想新增任何其他責任。
您的資料模型不應通知您的檢視
當我發現一個模型物件負責在某些資料發生變化時通知檢視時（通常使用資料繫結），我發瘋了。只是因為它的字面意思是個資料或領域物件，也有責任管理資料的顯示方式。
像往常一樣，分離關注。
您的領域模型應該（幾乎）沒有任何依賴
領域模型是一組類或函式，在領域層中分組，包含所有業務邏輯。該層完全沒有基礎設施。它應該是業務的純粹抽象。
如果我們改變渲染軟體的方式，領域模型仍然有效。如果我們更改資料儲存，領域模型仍然有效。如果我們決定停止使用我們最喜歡的Framework，域模型仍然有效。
領域模型只依賴於一件事：業務。