現在傳統的mvc開發基本上都是貧血模型 如以下** 我們工作中經常使用
//////////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
我們將所有業務邏輯都寫在servcie裡面 將bo和業務邏輯根據service分離開了,這是一種面向過程的風格開發方式
在貧血模型中，資料和業務邏輯被分割到不同的類中。充血模型（rich domain model）正好相反，資料和對應的業務邏輯被封裝到同乙個類中。因此，這種充血模型滿足物件導向的封裝特性，是典型的物件導向程式設計風格
主要用來指導如何解耦業務系統,劃分服務模組,定義業務領域模型及其互動 早在2023年就剔除,真正興起是在微服務興起的時候.微服務需要根據公司業務對服務進行合理的劃分。而ddd正好可以做到指導的作用
實際上ddd也是傳統的mvc三層 在service加了一層doman 跟貧血不一樣的是 bo除了包含資料 還包含了對應資料的業務處理
貧血模型:重service 輕bo 充血模型:輕service 重bo
大部分公司業務都比較簡單,就算基於充血模型設計 模型也比較單薄 ,與其絞盡腦汁設計充血模型不如直接使用貧血模型。而且業務也經常變 或者整體推翻重做
充血模式比貧血更加有難度,充血模型 是根據模型定義要暴露哪些操作 而不是貧血模型 我們先定義好資料表結構 然後根據資料表結構有哪些業務 就在service新增對應處理業務的方法
思維固化現在基本上的程式開發都是貧血模型 開發人員也是使用貧學模型,如果使用充血模型學習成本增加
業務複雜的專案應該優先考慮使用ddd開發模式
因為貧血模型 我們是基於業務再service定義個對資料表crud的操作,對業務耦合性比較大,無法重用,
而基於ddd則是根據模型定義好要暴露的操作 然後在service根據業務使用這些暴露的操作完成一系列業務,復用性更強 越複雜的系統對重用性以及易維護性要求更強
因為教程例子 是doman層沒有運算元據庫 感覺doman層很單薄 跟我理解的不一樣我就不貼出來了 有機會再補上
設計模式之美學習 設計原則之單一職責 四
一種理解是 把模組看作比類更加抽象的概念，類也可以看作模組。另一種理解是 把模組看作比類更加粗粒度的 塊，模組中包含多個類，多個類組成乙個模組。乙個類只負責完成乙個職責或者功能。也就是說，不要設計大而全的類，要設計粒度小 功能單一的類。換個角度來講就是，乙個類包含了兩個或者兩個以上業務不相干的功能，...
設計模式之美學習 迪公尺特原則 十一
能夠指導我們實現 高內聚 松耦合 的 迪公尺特原則的定義是 只與你的直接朋友交談，不跟 陌生人 說話 talk only to your immediate friends and not to strangers 其含義是 如果兩個軟體實體無須直接通訊，那麼就不應當發生直接的相互呼叫，可以通過第三...
設計原則之美學習筆記 設計原則
乙個類只負責完成乙個職責或者功能。不要設計大而全的類，要設計粒度小 功能單一的類。單一職責原則是為了實現 高內聚 低耦合，提高 的復用性 可讀性 可維護性。不同的應用場景 不同階段的需求背景 不同的業務層面，對同乙個類的職責是否單一，可能會有不同的判定結果。實際上，一些側面的判斷指標更具有指導意義和...