什麼是貧血模型？
貧血模型就是缺血了，缺東西，也就是只有資料但是沒有業務邏輯或者有業務邏輯但是沒有資料。
比如你有乙個計算類，他有乙個加法計算的方法。但是他不持有計算的資料。
和貧血模型對應的就是充血模型。
什麼是充血模型？
充血模型就是不缺血了，有資料同樣有業務邏輯。
比如你的計算類現在不只有加法計算，還有需要的資料。
我們現在進行的開發基本上都是基於貧血模型開發的。
比如乙個電商系統，有商品模型，但是乙個商品模型只有商品的基本資訊，資料。如果需要獲取乙個商品的總價，那麼我們需要呼叫model裡面的乙個方法來計算。這就是典型的貧血模型。
如果我們在商品模型裡面提供乙個計算總價的方法。把資料和業務邏輯放在一起，這就是充血模型。
充血模型要將資料和業務高度內聚在乙個類中，使得類更加飽滿，也是高內聚低耦合的一種實踐。不過充血模型需要更好的設計整個類才能實現。因為要考慮到擴充套件性，測試性，可讀性，復用性等。充血模型注定比貧血模型更加耗費時間，更加難以實現。
ddd的概念很早就有了，但是一直沒有火起來。現在又出現了充血模型的概念。
ddd的核心思想其實就是根據不同的領域，功能來設計建模，劃分模組。微服務的劃分就可以借鑑ddd的思想，根據不同的業務領域來劃分。
ddd可以用來指導我們如果做軟體設計，但是想要用好ddd，需要對自身的業務足夠理解，足夠熟練。
領域是乙個組織所做的事情以及其包含的一切。領域驅動設計就是從自身的領域出發，分析自身領域內的一切關聯關係，根據其設計我們的軟體。構造充血模型。也就是充血模型是和業務高度耦合的，完全從自身的領域出發進行設計。可以先將自身的領域細分出多個子領域，然後再每個子領域中設計出各自的領域模型。也就是充血模型。
比如電商領域可以分成使用者，商品，訂單，物流等子領域。然後設計出各自的實體物件，根據全域性領域的上下文來分析需要承擔哪些責任也就是哪些資料和業務邏輯。
DDD領域驅動設計 充血模型 貧血領域模型
最早廣泛應用源於ejb2，最強盛時期則是由spring創造，把 分離到不同的物件中 貧血領域模型是乙個存在已久的反模式，它不是個好東西。它完全和物件導向設計背道而馳。物件導向設計主張將資料和行為繫結在一起，而貧血領域模型則更像是一種面向過程設計。貧血領域模型的根本問題在於，它引入了領域模型設計的所有...
貧血模型，充血模型 領域驅動設計
很多業務系統都是基於 mvc 三層架構來開發的。雖然這種開發模式已經成為標準的 web 專案的開發模式，但它卻違反了物件導向程式設計風格，是一種徹徹底底的面向過程的程式設計風格。mvc 三層架構中的 m 表示 model，v 表示 view，c 表示 controller 它將整個專案分為三層 展示...
DDD 充血模型和失血模型
回到目錄 這幾年，狀態依舊不好，但在23點以後，狀態還可以，所以，靜下來，看點ddd，並把相關資訊記載一下，今天是除夕，不過，我寫文章時已經是大年初一了，呵呵，外面的炮聲響亮，但我的內心很平靜，也許是年齡大了，對於過年的感覺也已經淡化了吧，再或許是有些事情還放不在。今年的任務挺多的，目標也確實有點大...