幾種域模型的爭論持續很久了，尤其在
martin fowler
批判貧血的域模型後，爭論更加激烈，
martin
的文章我剛看到，他對貧血域模型的觀點我基本都同意，但是我得出的結論確和他不同。
我同意只含有屬性（甚至加上
crud
）的domain object
是不符合
oo的，這樣做很類似於使用事務指令碼和表模組方式，只是把取出的資料再封裝到類中。在這種模型下
domain object
更像乙個
dto和值物件。
同意域模型只包含屬性和
crud
沒有體現出域模型的本意，域模型實現域邏輯才能稱為域模型。從這兩點上說
martin
的觀點也是正確的。
但是總感覺有些不對的地方，畢竟自己和好多人一樣用這種模式很久了，能存在這麼久也是有原因的，有些人把這歸結於
orm（
nhibernate
）和dao
模式的廣泛使用，確實這兩種工具促使了這種模型的發揮範圍，但是從本質上說，這種模式是有其優點的，至少我認為他和含有業務邏輯的域模型（充血）比較起來是半斤八兩，貧血模型沒有比充血域模型差。
貧血模型的層次結構：
注：domain object實現一些易於繫結控制項的介面也可以當做dto使用，但是一般dto還是不能省的。圖中的icompare只是乙個特例，可能還要實現ilist等。
首先，貧血模型雖然不
oo，但是畢竟把資料封裝到類裡面了，這樣就為
service
層實現oo
打下了乙個基礎，要比表模組和事務指令碼好很多，從這點上看他也不等同於事務指令碼和表模組。
其次，把業務邏輯和域模型（貧血）分開是有優點的，至少把業務邏輯和業務資料分離了，雖然在理論上這種分離是沒有意思的也是非
oo的，但在實踐中這樣做至少分離了變化，實現難度也沒有增加，為什麼是不可以接受呢？難道只是因為他不oo？
再次，特別簡單是這種模型流行的基礎。如果使用
nhibernate
等orm
工具，很容易再第三方工具的配合下生成**，如果把
crud
從域中提取出來可以更方便的使用**生成。如果自己些對映可以很容易的在數基層實現
或者用activerecord。
再加上在簡單的應用中
domain object
可以當作
dto使用，這些都是貧血模型存在的理由。
他的缺點是導致服務層太龐大了，這一點可以把服務層拆分，然後再在這些細粒度的服務層上面封裝乙個
thinservice
層來解決。
另乙個缺點是，我直覺上認為在領域物件中不包含領域邏輯是很不合理的，但是又找不到他不合理的證據。
充血結構：
包含域邏輯的域物件（充血）沒有上面說的兩個缺點，他符合
oo，很容易實現乙個
thinservice
，感覺上這種模型很好。
首先，域物件包含了操作，是真正的域物件，域物件可以重用了,只是聽起來很美。
其次，服務層很薄（只包含跨多個域物件或者第三方邏輯的封裝），把域邏輯分離了一部分給域物件，變化容易控制，修改也容易。
但是這些優點，很多都是直覺上的，因為業務邏輯太複雜了也太容易變化了，這就造成讓域物件包含操作也不是乙個很合理的方式。
缺點是實現很難，即使用
orm工具也很複雜，更不要說自己寫對映層了。
總結：業務邏輯和業務資料耦合在一起是合理的，但是業務邏輯相較於業務資料是更易變的，從分離變化的角度來看是有必要把他們分開的，也就是貧血模式。同樣把dao從域物件剝離出來也沒有什麼必要，因為兩者都是相對穩定的。
所以我認為貧血的模型是比較實用的。
為什麼我們需要域
對很多剛開始鑽研微軟技術的朋友來說，域是乙個讓他們感到很頭疼的物件。域的重要性毋庸置疑，微軟的重量級服務產品基本上都需要域的支援，很多公司招聘工程師的要求中也都明確要求應聘者熟悉或精通active directory。但域對初學者來說顯得複雜了一些，眾多的技術術語，例如active director...
（原創）領域模型中貧血模型與充血模型的簡單區別
目錄 一 領域模型 二 區分 1.貧血模型 2.充血模型 領域模型 domain model 是對現實世界中物件的表示，又稱為領域物件模型 概念模型 業務實體，它通常都具有目標物件的特徵和行為，當多個領域模型結合在一起時，就可以完成各種業務邏輯，其實也是對現實世界中物件之間關聯關係的一種還原。這裡主...
馬化騰 我們對AI的未知仍然大於已知
techweb 7月8日訊息，在2021世www.cppcns.com界人工智慧大會上，騰訊公司董事會主席 首席執行官馬化騰表示，騰訊將和國際天文台共同發布探險計畫，利用上海優程式設計客棧圖實驗室的ai技術，用於尋找脈衝星，探索宇宙。他指出，ai技術不但能 上天 還能 進廠 入生活 目前已經有上海的...