貧血模型or領(lǐng)域模型(編輯修改稿)
2024-09-14 17:03 本頁(yè)面
【文章內(nèi)容簡(jiǎn)介】 類(lèi)使用了AccountDAO和TranferTransactionDAO，它的transfer方法負(fù)責(zé)整個(gè)轉(zhuǎn)帳操作，它首先判斷轉(zhuǎn)帳的金額必須大于0，然后判斷fromAccountId和toAccountId是一個(gè)存在的Account的accountId，如果不存在拋AccountNotExsitedException。接著判斷轉(zhuǎn)帳的金額是否大于fromAccount的余額，如果是則拋AccountUnderflowException。接著分別調(diào)用fromAccount和toAccount的setBalance來(lái)更新它們的余額。最后保存到數(shù)據(jù)庫(kù)并記錄交易。TransferServiceImpl負(fù)責(zé)所有的業(yè)務(wù)邏輯，驗(yàn)證是否超額提取并更新帳戶(hù)余額。一切并不復(fù)雜，對(duì)于這個(gè)例子來(lái)說(shuō)，貧血模型工作得非常好！這是因?yàn)檫@個(gè)例子相當(dāng)簡(jiǎn)單，業(yè)務(wù)邏輯也不復(fù)雜，一旦業(yè)務(wù)邏輯變得復(fù)雜，TransferServiceImpl就會(huì)膨脹。優(yōu)缺點(diǎn) 貧血模型的優(yōu)點(diǎn)是很明顯的：1. 被許多程序員所掌握，許多教材采用的是這種模型，對(duì)于初學(xué)者，這種模型很自然，甚至被很多人認(rèn)為是java中最正統(tǒng)的模型。 2. 它非常簡(jiǎn)單，對(duì)于并不復(fù)雜的業(yè)務(wù)(轉(zhuǎn)帳業(yè)務(wù))，它工作得很好，開(kāi)發(fā)起來(lái)非常迅速。它似乎也不需要對(duì)領(lǐng)域的充分了解，只要給出要實(shí)現(xiàn)功能的每一個(gè)步驟，就能實(shí)現(xiàn)它。 3. 事務(wù)邊界相當(dāng)清楚，一般來(lái)說(shuō)service的每個(gè)方法都可以看成一個(gè)事務(wù)，因?yàn)橥ǔervice的每個(gè)方法對(duì)應(yīng)著一個(gè)用例。（在這個(gè)例子中我使用了facade作為事務(wù)邊界，后面我要講這個(gè)是多余的) 其缺點(diǎn)為也是很明顯的：1. 所有的業(yè)務(wù)都在service中處理，當(dāng)業(yè)越來(lái)越復(fù)雜時(shí)，service會(huì)變得越來(lái)越龐大，最終難以理解和維護(hù)。 2. 將所有的業(yè)務(wù)放在無(wú)狀態(tài)的service中實(shí)際上是一個(gè)過(guò)程化的設(shè)計(jì)，它在組織復(fù)雜的業(yè)務(wù)存在天然的劣勢(shì)，隨著業(yè)務(wù)的復(fù)雜，業(yè)務(wù)會(huì)在service中多個(gè)方法間重復(fù)。 3. 當(dāng)添加一個(gè)新的UI時(shí)，很多業(yè)務(wù)邏輯得重新寫(xiě)。例如，當(dāng)要提供Web Service的接口時(shí)，原先為Web界面提供的service就很難重用，導(dǎo)致重復(fù)的業(yè)務(wù)邏輯（在貧血模型的分層圖中可以看得更清楚），如何保持業(yè)務(wù)邏輯一致是很大的挑戰(zhàn)。領(lǐng)域模型 接下來(lái)看看領(lǐng)域驅(qū)動(dòng)模型，與貧血模型相反，領(lǐng)域模型要承擔(dān)關(guān)鍵業(yè)務(wù)邏輯，業(yè)務(wù)邏輯在多個(gè)領(lǐng)域?qū)ο笾g分配，而Service只是完成一些不適合放在模型中的業(yè)務(wù)邏輯，它是非常薄的一層，它指揮多個(gè)模型對(duì)象來(lái)完成業(yè)務(wù)功能。包結(jié)構(gòu) 領(lǐng)域模型的實(shí)現(xiàn)一般包含如下包： infrastructure: 代表基礎(chǔ)設(shè)施層，一般負(fù)責(zé)對(duì)象的持久化。 domain：代表領(lǐng)域?qū)?。domain包中包括兩個(gè)子包，分別是model和service。model中包含模型對(duì)象，Repository（DAO)接口。它負(fù)責(zé)關(guān)鍵業(yè)務(wù)邏輯。service包為一系列的領(lǐng)域服務(wù)，之所以需要service，按照DDD的觀點(diǎn)，是因?yàn)轭I(lǐng)域中的某些概念本質(zhì)是一些行為，并且不便放入某個(gè)模型對(duì)象中。比如轉(zhuǎn)帳操作，它是一個(gè)行為，并且它涉及三個(gè)對(duì)象，fromAccount，toAccount和TransferTransaction，將它放入任一個(gè)對(duì)象中都不好。 application: 代表應(yīng)用層，它的主要提供對(duì)UI層的統(tǒng)一訪問(wèn)接口，并作為事務(wù)界限。 代碼實(shí)現(xiàn) 現(xiàn)在來(lái)看實(shí)現(xiàn)，照例先看model中的對(duì)象：Java代碼 1. publicclassAccount{ 2. privateStringaccountId。 3. privateBigDecimalbalance。 4. 5. privateOverdraftPolicyoverdraftPolicy= 6. 7. publicAccount(){} 8. 9. publicAccount(StringaccountId,BigDecimalbalance){ 10. (accountId)。 11. (balance==null||()=0)。 12. 13. =accountId。 14. =balance==null?:balance。 15. } 16. 17. publicStringgetAccountId(){ 18. returnaccountId。 19. } 20. 21. publicBigDecimalgetBalance(){ 22. returnbalance。 23. } 24. 25. publicvoiddebit(BigDecimalamount)throwsAccountUnderflowException{ 26. (()0)。 27. 28. if(!(this,amount)){ 29. thrownewAccountUnderflowException(this,amount)。 30. } 31. balance=(amount)。 32. } 33. 34. publicvoidcredit(BigDecimalamount){ 35. (()0)。 36. 37. balan
環(huán)評(píng)公示相關(guān)推薦
鄂ICP備17016276號(hào)-1