從最常規的分層結構來說，系統層次從上到下依次為：
表現層：主要是客戶端的展示。
服務層：直接為客戶端提供的服務或功能。也是系統所能對外提供的功能。
領域層：系統內的領域活動。
dao層：資料訪問物件，通過領域實體物件來操作
資料庫。
其中有些指導原則：
1、上層總是依賴其下層，依賴關係不跨層。
2、表現成除外，同一層之間方法不允許相互呼叫。這是實際開發中一些開發者容易范的錯誤！如果真是同一層之間存在方法呼叫，需要注意，這些呼叫都是一些上層不可見方法，比如一些工具方法等。
3、一切從服務層出發，從系統需要提供的功能進行分析，確定service介面中的方法。而不是從資料庫的表出發，建立dao，再創domain，然後service，這實際上是對系統分層的誤解。
4、系統最核心的設計就是將系統中的實體劃分為領域模型。在此
基礎上設計資料的dao層，並將這些活動暴露給服務層，服務層的實現依賴於領域活動。
5、每個介面的職責範圍明確有界。
在我所做的系統中，常常看到一些糟糕的編碼：系統設計從表開始，乙個表對應乙個dao，乙個dao對應乙個domain，乙個domain對應乙個service，實際上service的介面和dao的介面基本上完全一樣！導致service的介面方法超多！到了表現層，前台程式設計師在寫action的時候，action中反覆的呼叫service方法，**不堪入目。
正確的設計應該是，乙個領域活動會聚合對應乙個或一組dao，來完成乙個領域活動。而乙個服務可能包含兩個領域活動，比如乙個轉賬的業務，對應兩個領域活動。兩個帳戶的金額分別發生變化，需要操作一組領域活動，而每個活動需要操作很多表（呼叫多個dao）。 事務的控制我們可以放到service層。
目前，越來越多的架構師喜歡領域模型
驅動設計，針對系統的領域模型建模，然後上層直接是service，service下面就是領域活動層activity，從而去掉了dao層，這樣做的優點是系統設計思路更清晰，目標更明確。可以避免上面所說的乙個表對應乙個dao、service的情況。
但缺點是當領域活動發生變化的時候，會引起領域活動層**的變化。並且，當要更換持久化框架或者技術時候，領域活動要重新實現。
但綜合考慮起來，這樣帶來的優點也很多，而實際上更換資料庫和持久化框架的情況很少，因此這樣的設計也是有其合理性一面的。這樣做實際上是將原來的dao和domain層合併為乙個activity.但上層的設計思路還是一致的。
其實service層的設計也很講究，其中就是要控制service的數量，從service層往下，介面數量逐層增加。通常將乙個模組的服務都集中到乙個service中來處理。
每層中的每個介面都應該關注的是自己的那一塊，而不是吃著碗裡看著鍋裡，牛槽伸出個狗舌頭，最典型的例子就是乙個dao中胡亂操作別的表。這種凌亂的實現只會置專案經理與死地。也會為
軟體的維護帶來很大代價。
筆者曾遇到這樣的團隊，缺乏對整個專案的整體設計，乙個表乙個dao，對應乙個service，系統也不大，三四十張表，但是效能相當地下，經常down機。
最終發現，失敗不是開源框架和資料庫以及
應用伺服器和硬體
配置的錯，根源在於拙劣的設計導致。
應用OSCache提公升J2EE系統執行效能
cache是一種用於提高系統響應速度 改善系統執行效能的技術。尤其是在web應用中，通過快取頁面的輸出結果，可以很顯著的改善系統執行效能。本文中作者給大家介紹乙個實現j2ee框架中web應用層快取功能的開放源 專案 oscache。通過應用oscache，我們不但可以實現通常的cache功能，還能夠...
應用OSCache提公升J2EE系統執行效能
cache是一種用於提高系統響應速度 改善系統執行效能的技術。尤其是在web應用中，通過快取頁面的輸出結果，可以很顯著的改善系統執行效能。本文中作者給大家介紹乙個實現j2ee框架中web應用層快取功能的開放源 專案 oscache。通過應用oscache，我們不但可以實現通常的cache功能，還能夠...
談談你對J2EE的理解？
談談你對j2ee的理解？一方面 對j2ee的理解 1 範圍 針對企業級應用 特點 業務複雜 資料量大 2 開發 程式上採用分層的思想 物理上採用分步式的結構，而且程式開發都是基於元件或框架的 3 技術 考慮比較全面 如系統安全性 如加入一些認證 資料安全性 如備份策略 效能效率 如緩衝池 快取 4 ...