在閱讀了關於這種反模式以及這裏關於它的許多擔憂之後再次感到困惑。貧血領域模型與領域模型
如果我有一個域模型並捕獲必須在數據傳輸對象中保存的數據，那麼這是否會使我的域模型成爲數據的包裝？在那種情況下，我會使用貧血域模型。但是，如果我在該包裝上添加足夠的域邏輯，那麼它在什麼時候成爲真正的域模型呢？
我得到的印象是，捕獲域模型中必須堅持的內容違反了良好實踐並創建了貧血域模型反模式。但是，如果您使用關係數據庫，則無法避免單獨找出導致對象狀態並保存的部分。
由於我對這些概念很困惑，我不確定我寫的是否合理。隨意澄清。
它成爲一個「真正的」域模型時，它包含了所有（或大部分）行爲，構成了商業領域的（請注意，我強調業務邏輯，而不是UI或其他正交關注）。
如果您正在使用通用語言，並從領域專家越來越不斷的反饋，你就會知道，你在正確的軌道上，當他們看到你的域模型（專家應點頭）。如果你沒有做這些事情，你不會做DDD（Eric Evans speak about it）。
在DTO的基礎上：不要忽視它們。從實現的角度來看，您需要它們在不同層/層之間傳輸數據。您如何將DTO和真正的域對象結合在一起，實際上取決於您使用的技術。
，如前面的回答提到了，也許你的焦點數據和持久從真正域建模會讓你分心...
但是，如果我在該包裝上添加了足夠的領域邏輯，那麼它在什麼時候成爲真正的領域模型呢？
通過以偶然的方式添加東西來達到域模型是可能的，但是肯定不是域驅動的設計。 （我知道這並不是真的有用，我傾向於認爲自己非常以數據爲中心，並且在某些情況下需要真正努力從這個角度拉下自己的力量。）
感興趣的兩個項目出現在我的腦海中：