還是
martin fowler的peaa一書讀後引起的餘震，此書確實發人深省。
貧血domain model，"在這個領域空間裡，有一堆以名詞命名的物件。這些物件之間也同樣存在豐富的關聯結構，就如同真正的領域模型一樣。但是，這些物件所擁有的行為太少了。領域邏輯放在service layer中，並通過領域物件訪問資料庫。"（引自點空間）
martin fowler旗幟鮮明地反對它，其理由是：「基本上，貧血的領域模型的問題是，它付出了領域模型的所有成本，卻沒有產出任何收益」，這裡的成本，主要來自模型和關聯式資料庫之間的介面，必須額外使用orm工具。真正的領域模型的收益又是什麼呢？從巨集觀上說是可以應付複雜的業務邏輯需求，微觀上嘛，可以使用繼承和多型等物件導向的特徵，將資料和行為良好封裝，從而產生乙個oo愛好者所唯美追求的設計？
以下是我個人的一點想法，即「竊以為」：
貧血模型接近乙個靜態資料模型（e-r模型，或powerdesigner出產的cdm),如果這個資料庫設計最大程度地接近oo的思路來的（一種可持久化儲存方案），那麼orm的成本並不高，如果使用真正結合了行為的領域模型，使用了複雜的設計模式，勢必加入很多輔助類，控制類，這樣獲得了業務處理上的靈活性，很好地滿足了開閉原則，但在和資料庫的對映上麻煩增加了，貧血模型本身無罪，應該視實際需求及本身設計能力而選擇，我所遇到的專案（包括其他公司），有80%都使用事務指令碼型架構和貧血模型，相當多的成功案例。 一切以需求為準，oo原則充分考慮，struts webwork spring hibernate ...沒有哪個是不可或缺滴。架構中的細節以實踐作為檢驗唯一標準，因敵勢而製敵者，謂之神。
富領域模型和貧血領域模型
貧血領域模型乙個明顯的特徵是 它僅僅是看上去和領域模型一樣，都是物件，都以領域空間中定 義的名詞命名，這些物件通過實際領域模型中豐富的關係和結構相互關聯。但是觀察模型所持有的 業務邏輯時會發現，貧血模型中除了大量 getter 和 setter，幾乎沒有其他業務邏輯。當然，在使用貧血領域模型時，那些...
DDD領域驅動設計 充血模型 貧血領域模型
最早廣泛應用源於ejb2，最強盛時期則是由spring創造，把 分離到不同的物件中 貧血領域模型是乙個存在已久的反模式，它不是個好東西。它完全和物件導向設計背道而馳。物件導向設計主張將資料和行為繫結在一起，而貧血領域模型則更像是一種面向過程設計。貧血領域模型的根本問題在於，它引入了領域模型設計的所有...
領域模型 貧血模型 充血模型概念總結
領域模型 領域模型是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型 領域物件模型 分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。業務物件模型 也叫領域模型 domain model 是描述業務用例實現的物件模型。它是對業務角色和業務實體之間...