領域驅動設計，關鍵是要做領域建模，領域建模的結果叫領域模型。領域模型還有一個名字叫充血模型，以與貧血模型這個名稱做對應。

貧血領域模型的基本特徵是：

• 它第一眼看起來還真像這麼回事兒。專案中有許多物件，它們的命名都是根據領域來的。
• 物件之間有著豐富的連線方式，和真正的領域模型非常相似。
• 但當你檢視這些物件的行為時，會發現它們基本上沒有任何行為，僅僅是一堆getter/setter。

這些物件在設計之初就被定義為只能包含資料，不能加入領域邏輯；邏輯要全部寫入一組叫Service的物件中；而Service則構建在領域模型之上，需要使用這些模型來傳遞資料。

面向物件設計主張將資料和行為繫結在一起，而貧血領域模型則更像是一種面向過程設計。

貧血領域模型的根本問題是：

• 它引入了領域模型設計的所有成本，卻沒有帶來任何好處。
• 最主要的成本是將物件對映到資料庫中，從而產生了一個O/R（物件關係）對映層。

如果將所有行為都寫入到Service物件，那最終你會得到一組事務處理指令碼，從而錯過了領域模型帶來的好處。所以充血模型應用層要做薄，領域層做厚。

貧血模型的優點：簡單

• 對於只有少量業務邏輯的應用來說，使用起來非常自然；
• 開發迅速，易於理解；

注意：也不能完全排斥這種方式。

貧血模型的缺點：無法良好的應對複雜邏輯

• 隨著業務發展，不斷引入新的規則，可維護性變差。比如：和歐洲簽訂的合同使用另外一個規則...

總結

理論上OOP總是比面向過程程式設計要有更豐富的語義、更合理的組織、更強的可維護性，看起來應該廣泛使用。

但是它更難掌握，其中最大的難關就是“如何設計充血模型”，或者說“如何從複雜的業務中分離出恰到好處且包含語義邏輯行為並放到合適的物件中”。

所以，需要通過團隊能力、業務複雜度、業務穩定還是快速試錯等因素來決定使用那個模型。