很多業務系統都是基於 mvc 三層架構來開發的。雖然這種開發模式已經成為標準的 web 專案的開發模式，但它卻違反了物件導向程式設計風格，是一種徹徹底底的面向過程的程式設計風格。 mvc 三層架構中的
m 表示 model，v 表示 view，c 表示 controller
。它將整個專案分為三層：展示層、邏輯層、資料層。mvc 三層開發架構是乙個比較籠統的分層方式，落實到具體的開發層面，很多專案也並不會 100% 遵從 mvc 固定的分層方式，而是會根據具體的專案需求，做適當的調整。
目前幾乎所有的業務後端系統，都是基於貧血模型的。
很多業務系統都是基於 mvc 三層架構來開發的。實際上，更確切點講，這是一種基於
貧血模型的 mvc 三層架構
開發模式。
在貧血模型中，資料和業務邏輯被分割到不同的類中。
資料和對應的業務邏輯被封裝到同乙個類中。
領域驅動設計，即 ddd，主要是用來指導如何解耦業務系統，劃分業務模組，定義業務領域模型及其互動。 除了
監控、呼叫鏈追蹤、api 閘道器
等服務治理系統的開發之外，微服務還有另外乙個更加重要的工作，那就是針對公司的業務，合理地做微服務拆分。而
領域驅動設計恰好就是用來指導劃分服務
的。所以，微服務加速了領域驅動設計的盛行。領域驅動設計有點兒類似敏捷開發、soa、paas 等概念，聽起來很高大上，但實際上只值「五分錢」。
面向過程程式設計風格有種種弊端，比如，
資料和操作分離之後，資料本身的操作就不受限制了
。任何**都可以隨意修改資料
為什麼基於貧血模型的傳統開發模式如此受歡迎？
第一點原因是，大部分情況下，我們開發的系統業務可能都比較簡單，簡單到就是基於 sql 的 crud 操作.
第二點原因是，充血模型的設計要比貧血模型更加有難度。
第三點原因是，思維已固化，轉型有成本。
什麼專案應該考慮使用基於充血模型的 ddd 開發模式？
基於充血模型的 ddd 開發模式，更適合業務複雜的系統開發。比如，包含各種利息計算模型、還款模型等複雜業務的金融系統。
這兩種開發模式，落實到**層面，區別不就是乙個將業務邏輯放到 service 類中，乙個將業務邏輯放到 domain 領域模型中嗎？為什麼基於貧血模型的傳統開發模式，就不能應對複雜業務系統的開發？ 那就是兩種不同的開發模式會導致不同的開發流程。基於充血模型的 ddd 開發模式的開發流程，在應對複雜業務系統的開發的時候更加有優勢。
DDD領域驅動設計 充血模型 貧血領域模型
最早廣泛應用源於ejb2，最強盛時期則是由spring創造，把 分離到不同的物件中 貧血領域模型是乙個存在已久的反模式，它不是個好東西。它完全和物件導向設計背道而馳。物件導向設計主張將資料和行為繫結在一起，而貧血領域模型則更像是一種面向過程設計。貧血領域模型的根本問題在於，它引入了領域模型設計的所有...
領域模型 貧血模型 充血模型概念總結
領域模型 領域模型是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型 領域物件模型 分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。業務物件模型 也叫領域模型 domain model 是描述業務用例實現的物件模型。它是對業務角色和業務實體之間...
領域模型 貧血模型 充血模型概念總結
領域模型 領域模型是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型 領域物件模型 分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。業務物件模型 也叫領域模型 domain model 是描述業務用例實現的物件模型。它是對業務角色和業務實體之間...