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