今天剛好跟同事聊到充血模型的概念，決定轉貼小朱大的這篇，順手收進我的筆記庫：
這裡貧血、那裡充血，到底資料模型要怎麼設計？ - 小朱® 的技術隨手寫

首先我們先看一下貧血模型的部份，比較常見的應該就是單純放一下資料用的 DTO（Data Transfer Object）：

貧血模型之所以為貧血，其最大原因是，不論是 DTO 或是 POCO，它的業務邏輯都操控在別人手上，自己沒辦法去維護自己的業務規則，以上面 DTO 或 POCO 作為例子，它們都沒有內建的處理存款與提款的程式碼，都要倚賴外部程式

當業務邏輯只能由別人處理時，相對的就破壞了這個領域知識的內聚力，也提高了向外的耦合性，而且它並沒有辦法自我處理自己的領域知識，在後續系統的擴充與延長時，若與別人共用這個模型時，別人也一樣要實作這類領域知識，從而發生領域知識不一致的可能，導致系統設計的風險。

因此，若系統內的業務邏輯、流程或知識會有共用的可能性時，就應該要考慮以領域模型的方式設計，而不是使用 DTO 或 POCO 的設計作法。

而相對的，充血模型則是：

所謂的充血模型，只是大家在學校學過物件導向程式設計中，具有足夠內聚力的類別而己，但用一個新名詞來講，一個平凡無奇的概念突然瞬間高大上了起來。

一個充血模型，封裝 (Encapsulation) 的特性會十分明顯，它該有的資料就是它自己維護，外部想要對這個模型的資料做異動，就只能使用它所開放的方法 API 執行…這不就教科書上說的嗎？

在最後一段，小朱大有列出這兩種模型適用的時機。

例如說，應用程式很小、資料單純的時候，就可以考慮貧血模型；而如果某些領域知識會需要重複使用的時候，就可以考慮充血模型等等，有興趣的朋友可以再點進去參考一下。

之前在維護三層式的專案時，各層之間都是用 DTO 來傳遞資料。就像工廠流水線一樣，到了某一段就把資料倒出來處理處理，然後塞到另一個 DTO 傳到下一站。

後來到了現在的公司，才接觸到貧血充血這些名詞。但想想物件會動(?)好像也是理所當然的…吧？

那麼，今天的轉貼就到這裡。我們明天見