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

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

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

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

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

DAO層：數(shù)據(jù)訪問對象，通過領(lǐng)域?qū)嶓w對象來操作數(shù)據(jù)庫。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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