前景
我們都知道，現在很多專案都是基於貧血模型的mvc三層框架。
雖然這種開發模式已經成為了標準的web專案的開發模式，但是它卻違反了物件導向的程式設計風格，是一種徹底的面向過程的程式設計風格，因此有人稱之為反模式。
什麼是mvc
mvc三層架構中，m表示model， v表示view，c表示controller。將整個專案分為三層：展示層、邏輯層、資料層。不過很多專案也不會100%遵從mvc固定的分層方式，而是會根據專案具體需求做適當調整。比如很多的web專案都把後端專案分為repository層、service層、controller層。
什麼是貧血模型？
舉個例子
// controller+vo(view object) //
public class usercontroller
}public class uservo
// service+bo(business object) //
public class userservice
}public class userbo
// repository+entity //
public class userrepository
}public class userentity
像userbo這樣，只包含資料，不包含業務邏輯的類，就叫做貧血模型。
什麼是充血模型
充血模型和貧血模型剛好相反，資料和對應的業務邏輯被封裝到同乙個類中。因此，充血模型滿足物件導向的封裝特性，是典型的物件導向程式設計風格
什麼是領域驅動設計
領域驅動設計，即ddd，主要是用來指導如何解耦業務系統，劃分業務模型，定義業務領域模型及其互動。
在基於充血模型的ddd開發模式中，service層包含service類和domain類兩部分，domain就相當於貧血模型中的bo。不過domain與bo的區別在於它是基於充血模型開發的，既包含資料，也包含業務邏輯。而service類變得非常單薄。
做好領域驅動設計的關鍵是，看你對自己所做的業務的熟悉程度，而不是對領域驅動設計這個概念本身的掌握程度
總結一下： 基於貧血模型的開發模式，重service輕bo；基於充血模型的ddd開發模式，輕sercie重domain
為什麼基於貧血模型的傳統開發模式如此受歡迎
什麼專案應該考慮使用基於充血模型的ddd開發模式
在我們平時的開發中，我們大部分就是sql驅動（sql-driven）的開發模式。 我們接到乙個後端介面需求的時候，就去看介面需要的資料對應到資料庫中，需要哪張表或者哪幾張表，然後思考如何編寫sql語句來獲取資料。之後就是定義entity、bo、vo，然後模板式的給對應的repository、service、controller類新增**。
業務邏輯包裹到乙個大的sql語句中，而service層可以做的事情很少，sql都是針對特定的業務功能編寫的，復用性。當要開發另外乙個業務功能的時候，只能重新寫個滿足新需求的sql，這就可能導致各種長得差不多，區別很小的sql語句遍地都是。
所以在這個過程中，很少有人會應用領域模型、oop的概念，也很少有**復用意識，對於簡單業務系統來說，這種開發方式問題不大。但對於複雜業務系統的開發來說，這樣的開發方式會讓**越來越混亂，最終導致無法維護。
如果在專案中，應用基於充血模型的ddd的開發模式，那對應的開發流程完全不一樣。在這種開發模式下，我們需要實現理清楚所有業務，定義領域模所包含的屬性和方法。領域模型相當於可復用的業務中間層。 新功能需求的開發，都基於之前定義好的這些領域模型來完成。
越複雜的系統，對**的復用性、易維護性要求就越高，我們就越應該花更多的時間和精力在前期設計上，而基於充血模型的ddd開發模式，正好需要我們前期做大量的業務調研、領域模型設計，所以它更加適合這種複雜系統的開發
你真的物件導向了嗎？充血模式和貧血模式
還記得我們剛開始學物件導向的時候嗎？物件裡面有什麼？屬性和行為。但時至今日，我們的物件只有屬性，何來行為一說呀！充血模式和貧血模式 貧血模型 是指領域物件裡只有get和set方法，或者包含少量的crud方法，所有的業務邏輯都不包含在內而是放在business logic層。優點是系統的層次結構清楚，...
物件導向設計模式學習（一） 物件導向設計模式與原則
1。軟體設計模式是一些常見問題的一般解決案。2。物件導向設計模式是在物件導向開發中描述物件之間資訊通訊的組織關係。3。面象物件的三個特點 封裝 內部實現的隱藏 繼承 實現 復用 多型 改寫物件的行為 4。實現封裝，繼承，多型並不代表就是乙個面象物件模式設計，是面象物件模式的設計才導致了封裝，繼承，多...
物件導向設計模式與原則
最近在學習李建忠老師一系列的關於物件導向設計模式的課程，就想著把總結下來，以便自己以後的學習，設計模式是乙個比較空洞的話題，隨著我們的程式設計經驗的積累，我們能增加對它的理解，這是乙個日積月累的過程，但是我們應該在平時的程式設計過程中學會思考和分析，想一想在某種特定的場景下使用什麼樣的設計模式，怎樣...