【正文】 (fromAccountId)。 if (fromAccount == null) throw new AccountNotExistedException(fromAccountId)。 Account toAccount = (toAccountId)。 if (toAccount == null) throw new AccountNotExistedException(toAccountId)。 (amount)。 (amount)。 (fromAccount)。 // 對(duì)Hibernate來(lái)說(shuō)這不是必須的 (toAccount)。 // 對(duì)Hibernate來(lái)說(shuō)這不是必須的 return (fromAccountId, toAccountId, amount)。 } }與貧血模型中的TransferServiceImpl相比，最主要的改變?cè)谟跇I(yè)務(wù)邏輯被移走了，由Account類(lèi)來(lái)實(shí)現(xiàn)。對(duì)于這樣一個(gè)簡(jiǎn)單的例子，領(lǐng)域模型沒(méi)有太多優(yōu)勢(shì)，但是仍然可以看到代碼的實(shí)現(xiàn)要簡(jiǎn)單一些。當(dāng)業(yè)務(wù)變得復(fù)雜之后，領(lǐng)域模型的優(yōu)勢(shì)就體現(xiàn)出來(lái)了。優(yōu)缺點(diǎn) 其優(yōu)點(diǎn)是：1. 領(lǐng)域模型采用OO設(shè)計(jì)，通過(guò)將職責(zé)分配到相應(yīng)的模型對(duì)象或Service，可以很好的組織業(yè)務(wù)邏輯，當(dāng)業(yè)務(wù)變得復(fù)雜時(shí)，領(lǐng)域模型顯出巨大的優(yōu)勢(shì)。 2. 當(dāng)需要多個(gè)UI接口時(shí)，領(lǐng)域模型可以重用，并且業(yè)務(wù)邏輯只在領(lǐng)域?qū)又谐霈F(xiàn)，這使得很容易對(duì)多個(gè)UI接口保持業(yè)務(wù)邏輯的一致(從領(lǐng)域模型的分層圖可以看得更清楚)。其缺點(diǎn)是：1. 對(duì)程序員的要求較高，初學(xué)者對(duì)這種將職責(zé)分配到多個(gè)協(xié)作對(duì)象中的方式感到極不適應(yīng)。 2. 領(lǐng)域驅(qū)動(dòng)建模要求對(duì)領(lǐng)域模型完整而透徹的了解，只給出一個(gè)用例的實(shí)現(xiàn)步驟是無(wú)法得到領(lǐng)域模型的，這需要和領(lǐng)域?qū)＜业某浞钟懻?。錯(cuò)誤的領(lǐng)域模型對(duì)項(xiàng)目的危害非常之大，而實(shí)現(xiàn)一個(gè)好的領(lǐng)域模型非常困難。 3. 對(duì)于簡(jiǎn)單的軟件，使用領(lǐng)域模型，顯得有些殺雞用牛刀了。 我的看法 這部分我將提出一些可能存在爭(zhēng)議的問(wèn)題并提出自己的看法。軟件分層 理解軟件分層、明晰每層的職責(zé)對(duì)于理解領(lǐng)域模型以及代碼實(shí)現(xiàn)是有好處的。軟件一般分為四層，分別為表示層，應(yīng)用層，領(lǐng)域?qū)雍突A(chǔ)設(shè)施層。軟件領(lǐng)域中另外一個(gè)著名的分層是TCP/IP分層，分為應(yīng)用層,運(yùn)輸層,網(wǎng)際層和網(wǎng)絡(luò)接口層。我發(fā)現(xiàn)它們之間存在對(duì)應(yīng)關(guān)系，見(jiàn)下表：TCP/IP分層 軟件分層 表示層 負(fù)責(zé)向用戶(hù)顯示信息。應(yīng)用層 負(fù)責(zé)處理特定的應(yīng)用程序細(xì)節(jié)。如FTP,SMTP等協(xié)議。 應(yīng)用層 定義軟件可以完成的工作，指揮領(lǐng)域?qū)拥膶?duì)象來(lái)解決問(wèn)題。它不負(fù)責(zé)業(yè)務(wù)邏輯，是很薄的一層。運(yùn)輸層 兩臺(tái)主機(jī)上的應(yīng)用程序提供端到端的通信。主要包括TCP,UDP協(xié)議。 領(lǐng)域?qū)?負(fù)責(zé)業(yè)務(wù)邏輯，是業(yè)務(wù)軟件的核心。網(wǎng)際層 處理分組在網(wǎng)絡(luò)中的活動(dòng)，例如分組的選路。主要包括IP協(xié)議。網(wǎng)絡(luò)接口層 操作系統(tǒng)中的設(shè)備驅(qū)動(dòng)程序和計(jì)算機(jī)中對(duì)應(yīng)的網(wǎng)絡(luò)接口卡。它們一起處理與電纜（或其他任何傳輸媒介）的物理接口細(xì)節(jié)?；A(chǔ)設(shè)施層 為上層提供通用技術(shù)能力，如消息發(fā)送，數(shù)據(jù)持久化等。對(duì)于TCP/IP來(lái)說(shuō)，運(yùn)輸層和網(wǎng)際層是最核心的，這也是TCP/IP名字的由來(lái)，就像領(lǐng)域?qū)右彩擒浖詈诵牡囊粚??？梢钥闯鲱I(lǐng)域模型的包結(jié)構(gòu)與軟件分層是一致的。在軟件分層中，表示層、領(lǐng)域?qū)雍突A(chǔ)設(shè)施層都容易理解，難理解的是應(yīng)用層，很容易和領(lǐng)域?qū)又蠸ervice混淆。領(lǐng)域Service屬于領(lǐng)域?qū)?，它需要承?dān)部分業(yè)務(wù)概念，并且這個(gè)業(yè)務(wù)概念不易放入模型對(duì)象中。應(yīng)用層服務(wù)不承擔(dān)任何業(yè)務(wù)邏輯和業(yè)務(wù)概念，它只是調(diào)用領(lǐng)域?qū)又械膶?duì)象（服務(wù)和模型）來(lái)完成自己的功能。應(yīng)用層為表示層提供接口，當(dāng)UI接口改變一般也會(huì)導(dǎo)致應(yīng)用層接口改變，也可能當(dāng)UI接口很相似時(shí)應(yīng)用層接口不用改變，但是領(lǐng)域?qū)?包括領(lǐng)域服務(wù))不能變動(dòng)。例如一個(gè)應(yīng)用同時(shí)提供Web接口和Web Service接口時(shí)，兩者的應(yīng)用層接口一般不同，這是因?yàn)閃eb Service的接口一般要粗一些?？梢院蚑CP/IP的層模型進(jìn)行類(lèi)比，開(kāi)發(fā)一個(gè)FTP程序和MSN聊天程序，它們的應(yīng)用層不同，但是可以同樣利用TCP/IP協(xié)議，TCP/IP協(xié)議不用變。與軟件分層不同的是，當(dāng)同樣開(kāi)發(fā)一個(gè)FTP程序時(shí)，如果只是UI接口不同，一個(gè)是命令行程序，一個(gè)是圖形界面，應(yīng)用層不用變（利用的都是FTP服務(wù)）。下圖給出領(lǐng)域模型中的分層：Repository接口屬于領(lǐng)域?qū)?可能有人會(huì)將Repository接口，相當(dāng)于貧血模型中的DAO接口，歸于基礎(chǔ)設(shè)施層，畢竟在貧血模型中DAO是和它的實(shí)現(xiàn)放在一起。這就涉及Repository 接口到底和誰(shuí)比較密切？應(yīng)該和domain層比較密切，因?yàn)镽epository接口是由domain層來(lái)定義的。用TCP/IP來(lái)類(lèi)比，網(wǎng)際層支持標(biāo)準(zhǔn)以太網(wǎng)、令牌環(huán)等網(wǎng)絡(luò)接口，支持接口是在網(wǎng)際層中定義的，沒(méi)有在網(wǎng)際層定義的網(wǎng)絡(luò)接口是不能被網(wǎng)際層訪問(wèn)的。那么為什么在貧血模型中DAO的接口沒(méi)有放在model包中，這是因?yàn)樨氀Ｐ椭蠨AO的接口是由service來(lái)定義的，但是為什么DAO接口也沒(méi)有放在service包中，我無(wú)法解釋?zhuān)凑瘴业挠^點(diǎn)DAO接口放在service包中要更好一些，將DAO接口放在dao包或許有名稱(chēng)上對(duì)應(yīng)的考慮。對(duì)于領(lǐng)域模型，將Repository接口放入infrastructure包中會(huì)引入包的循環(huán)依賴(lài)，Repository依賴(lài)Domain，Domain依賴(lài)Repository。然而對(duì)于貧血模型，將DAO接口放入dao包中則不會(huì)引入包循環(huán)依賴(lài)，只有service對(duì)DAO和model的依賴(lài)，而沒(méi)有反方向的依賴(lài)，這也導(dǎo)致service包很不穩(wěn)定，service又正是放置業(yè)務(wù)邏輯的地方。JDepend這個(gè)工具可以檢測(cè)包的依賴(lài)關(guān)系。貧血模型中Facade有何用？ 我以前的做一個(gè)項(xiàng)目使用的就是貧血模型，使用了service和facade，當(dāng)我們討論service和facade有什么區(qū)別時(shí)，很少有人清楚，最終結(jié)果facade就是一個(gè)空殼，它除了將方法實(shí)現(xiàn)委托給相應(yīng)的service方法，不做任何事，它們的接口中的方法都一樣。Facade應(yīng)該是主要充當(dāng)遠(yuǎn)程訪問(wèn)的門(mén)面，這在EJB時(shí)代相當(dāng)普遍，自從Rod Johson叫嚷without EJB之后，大家對(duì)EJB的熱情降了很多，對(duì)許多使用貧血模型的應(yīng)用程序來(lái)說(shuō)，facade是沒(méi)有必要的。貧血模型中的service在本質(zhì)上屬于應(yīng)用層的東西。當(dāng)然如果確實(shí)需要提供遠(yuǎn)程訪問(wèn)，那么遠(yuǎn)程Facade(或許叫做Remote Service更好)也是很有用的，但是它仍然屬于應(yīng)用層，只不過(guò)在技術(shù)層面上將它的實(shí)現(xiàn)委托給對(duì)應(yīng)的Service。下圖是貧血模型的分層：從上面的分層可以看出貧血模型實(shí)際上相當(dāng)于取消掉了領(lǐng)域?qū)樱驗(yàn)轭I(lǐng)域?qū)硬](méi)有包含業(yè)務(wù)邏輯。DAO到底有沒(méi)有必要？ 貧血模型中的DAO或領(lǐng)域模型中的Repository到底有沒(méi)有必要？有人認(rèn)為DAO或者說(shuō)Repository是充血模型的大敵，對(duì)此我無(wú)論如何也不贊同。DAO或Repository是負(fù)責(zé)持久化邏輯的，如果取消掉DAO或Repository，將持久化邏輯直接寫(xiě)入到model對(duì)象中，勢(shì)必造成model對(duì)象承擔(dān)不必要的職責(zé)。雖然現(xiàn)在的ORM框架已經(jīng)做得很好了，持久化邏輯還是需要大量的代碼，持久化邏輯的摻入會(huì)使model中的業(yè)務(wù)邏輯變得模糊。允許去掉DAO的一個(gè)必要條件就是Java的的持久化框架必須足夠先進(jìn)，持久化邏輯的引入不會(huì)干擾業(yè)務(wù)邏輯，我認(rèn)為這在很長(zhǎng)一段時(shí)間內(nèi)將無(wú)法做到。在rails中能夠?qū)AO去掉的原因就是rail中實(shí)現(xiàn)持久化邏輯的代碼很簡(jiǎn)潔直觀，這也與ruby的表達(dá)能力強(qiáng)有關(guān)系。DAO的另外一個(gè)好處隔離數(shù)據(jù)庫(kù)，這可以支持多個(gè)數(shù)據(jù)庫(kù)，甚至可以支持文件存儲(chǔ)?；贒AO的這些優(yōu)點(diǎn)，我認(rèn)為，即使將來(lái)Java的持久化框架做得足夠優(yōu)秀，使用DAO將持久化邏輯從業(yè)務(wù)邏輯中分離開(kāi)來(lái)還是十分必要的，況且它們本身就應(yīng)該分離。結(jié)束語(yǔ) 在這篇文章里，我使用了一個(gè)轉(zhuǎn)帳例子來(lái)描述領(lǐng)域模型和貧血模型的不同，實(shí)現(xiàn)代碼可以從附件中下載，我推薦你看下附件代碼，這會(huì)對(duì)領(lǐng)域模型和貧血模型有個(gè)更清楚的認(rèn)識(shí)。我談到了軟件的分層，以及貧血模型和領(lǐng)域模型的實(shí)現(xiàn)又是怎樣對(duì)應(yīng)到這些層上去的，最后是對(duì)DAO(或Repository)的討論。以上只是我個(gè)人觀點(diǎn)，如有不同意見(jiàn)歡迎指出。