J2EE分層設(shè)計(jì)是Java企業(yè)應(yīng)用的最基本的設(shè)計(jì)思想。

從最常規(guī)的分層結(jié)構(gòu)來(lái)說(shuō)，系統(tǒng)層次從上到下依次為：

表現(xiàn)層：主要是客戶端的展示。

服務(wù)層：直接為客戶端提供的服務(wù)或功能。也是系統(tǒng)所能對(duì)外提供的功能。

領(lǐng)域?qū)樱合到y(tǒng)內(nèi)的領(lǐng)域活動(dòng)。

DAO層：數(shù)據(jù)訪問(wèn)對(duì)象，通過(guò)領(lǐng)域?qū)嶓w對(duì)象來(lái)操作數(shù)據(jù)庫(kù)。

其中有些指導(dǎo)原則：

1、上層總是依賴其下層，依賴關(guān)系不跨層。

2、表現(xiàn)成除外，同一層之間方法不允許相互調(diào)用。這是實(shí)際開(kāi)發(fā)中一些開(kāi)發(fā)者容易范的錯(cuò)誤！如果真是同一層之間存在方法調(diào)用，需要注意，這些調(diào)用都是一些上層不可見(jiàn)方法，比如一些工具方法等。

3、一切從服務(wù)層出發(fā)，從系統(tǒng)需要提供的功能進(jìn)行分析，確定Service接口中的方法。而不是從數(shù)據(jù)庫(kù)的表出發(fā)，創(chuàng)建DAO，再創(chuàng)Domain，然后Service，這實(shí)際上是對(duì)系統(tǒng)分層的誤解。

4、系統(tǒng)最核心的設(shè)計(jì)就是將系統(tǒng)中的實(shí)體劃分為領(lǐng)域模型。在此基礎(chǔ)上設(shè)計(jì)數(shù)據(jù)的DAO層，并將這些活動(dòng)暴露給服務(wù)層，服務(wù)層的實(shí)現(xiàn)依賴于領(lǐng)域活動(dòng)。

5、每個(gè)接口的職責(zé)范圍明確有界。

在我所做的系統(tǒng)中，常常看到一些糟糕的編碼：系統(tǒng)設(shè)計(jì)從表開(kāi)始，一個(gè)表對(duì)應(yīng)一個(gè)DAO，一個(gè)DAO對(duì)應(yīng)一個(gè)domain，一個(gè)Domain對(duì)應(yīng)一個(gè)Service，實(shí)際上Service的接口和DAO的接口基本上完全一樣！導(dǎo)致Service的接口方法超多！到了表現(xiàn)層，前臺(tái)程序員在寫(xiě)Action的時(shí)候，Action中反復(fù)的調(diào)用Service方法，代碼不堪入目。

正確的設(shè)計(jì)應(yīng)該是，一個(gè)領(lǐng)域活動(dòng)會(huì)聚合對(duì)應(yīng)一個(gè)或一組DAO，來(lái)完成一個(gè)領(lǐng)域活動(dòng)。而一個(gè)服務(wù)可能包含兩個(gè)領(lǐng)域活動(dòng)，比如一個(gè)轉(zhuǎn)賬的業(yè)務(wù)，對(duì)應(yīng)兩個(gè)領(lǐng)域活動(dòng)。兩個(gè)帳戶的金額分別發(fā)生變化，需要操作一組領(lǐng)域活動(dòng)，而每個(gè)活動(dòng)需要操作很多表（調(diào)用多個(gè)DAO）。 事務(wù)的控制我們可以放到Service層。

目前，越來(lái)越多的架構(gòu)師喜歡領(lǐng)域模型驅(qū)動(dòng)設(shè)計(jì)，針對(duì)系統(tǒng)的領(lǐng)域模型建模，然后上層直接是Service，Service下面就是領(lǐng)域活動(dòng)層Activity，從而去掉了DAO層，這樣做的優(yōu)點(diǎn)是系統(tǒng)設(shè)計(jì)思路更清晰，目標(biāo)更明確。可以避免上面所說(shuō)的一個(gè)表對(duì)應(yīng)一個(gè)DAO、Service的情況。

但缺點(diǎn)是當(dāng)領(lǐng)域活動(dòng)發(fā)生變化的時(shí)候，會(huì)引起領(lǐng)域活動(dòng)層代碼的變化。并且，當(dāng)要更換持久化框架或者技術(shù)時(shí)候，領(lǐng)域活動(dòng)要重新實(shí)現(xiàn)。

但綜合考慮起來(lái)，這樣帶來(lái)的優(yōu)點(diǎn)也很多，而實(shí)際上更換數(shù)據(jù)庫(kù)和持久化框架的情況很少，因此這樣的設(shè)計(jì)也是有其合理性一面的。這樣做實(shí)際上是將原來(lái)的DAO和Domain層合并為一個(gè)Activity.但上層的設(shè)計(jì)思路還是一致的。

其實(shí)Service層的設(shè)計(jì)也很講究，其中就是要控制Service的數(shù)量，從Service層往下，接口數(shù)量逐層增加。通常將一個(gè)模塊的服務(wù)都集中到一個(gè)Service中來(lái)處理。

每層中的每個(gè)接口都應(yīng)該關(guān)注的是自己的那一塊，而不是吃著碗里看著鍋里，牛槽伸出個(gè)狗舌頭，最典型的例子就是一個(gè)DAO中胡亂操作別的表。這種凌亂的實(shí)現(xiàn)只會(huì)置項(xiàng)目經(jīng)理與死地。也會(huì)為軟件的維護(hù)帶來(lái)很大代價(jià)。

筆者曾遇到這樣的團(tuán)隊(duì)，缺乏對(duì)整個(gè)項(xiàng)目的整體設(shè)計(jì)，一個(gè)表一個(gè)DAO，對(duì)應(yīng)一個(gè)Service，系統(tǒng)也不大，三四十張表，但是性能相當(dāng)?shù)叵拢?jīng)常down機(jī)。

最終發(fā)現(xiàn)，失敗不是開(kāi)源框架和數(shù)據(jù)庫(kù)以及應(yīng)用服務(wù)器和硬件配置的錯(cuò)，根源在于拙劣的設(shè)計(jì)導(dǎo)致。