貧血模型 - DDD - The Domain Driven Design

這種反模式的根本恐怖之處在於它與物件導向設計的基本思想相悖; 這是將資料和過程結合在一起。

Vaughn Vernon，IDDD，2013年：

貧血領域模型每天都出現在我們行業的各個角落。問題是，大多數開發人員似乎認為這是完全正常的，並且不認識到在他們的系統上使用時會產生嚴重的副作用。這是一個真正的問題。

因為貧血模型中沒有邏輯，因此，負責呼叫貧血模型的 客戶端負責解釋領域物件的用途和用途。通常，業務邏輯最終會在名為服務Services等其他類中實現，這些類會轉換領域物件的狀態。當然，這種方法會導致許多設計問題和缺點。貧血模型導致耦合的大服務

避免貧血領域模型的方法

• 使用private setters.。如果讓模型物件的屬性直接由外部客戶端直接定義，您將失去使用領域事件的機會，您將不得不在實體外的外部方法中驗證您的實體。
• 始終驗證您的實體的狀態，您的實體必須自我驗證。
• 避免沒有引數的建構函式。當然，您的物件需要一些初始化資料來維持有效狀態。
• 領域服務被開發人員用作真正的銀子彈，但最終成為貧血模型的最大原因。
• 小心ORM，他們負責自動建立域物件，生成真正的公共setter和公共getter容器，這導致了一個貧血模型。
• 不要使用事務指令碼[EAA第110頁的P]。
• 使用OOP，當然程式程式設計比物件導向程式設計更容易，請記住正確使用OOP是對付貧血模型的一個很好的補救措施。

為什麼人們喜歡貧血模型？
我們的許多行業都是由樣本程式碼追隨者組成的，但是，通常，示例程式碼專注於以最簡單的方式演示某些概念，而不必擔心良好的設計原則。

過度簡化的示例程式碼（通常演示了幾個getter和setter）每天都會被複制，而無需考慮專案。