引言
分層結構是目前復雜應用系統開發時普遍使用的模式，軟件中層之間的依賴關系約束是比較寬松的，并不要求上層僅可以依賴于直接下層，而是上層可以依賴于它的所有下層。
設計中我們會把各種系統的各種組件映射至不同層中，而在我所接觸的一些實際項目中設計人員在映射這種組件和層間的關系時經常無意中破壞了層結構的依賴關系約束。
圖表 1 典型分層結構
設計中的常見問題
問題一:數據傳輸對象（DTO）是否應該屬于業務層？
在J2EE開發的經典著作《Core J2EE Patterns》中數據傳輸對象被劃分在業務層模式中，那么是否數據傳輸對象應該被映射到業務層呢？
數據訪問對象（DAO）在該著作中是被映射到整合層的，這樣就會出現一個違反層依賴約束的問題，因為數據訪問對象是要依賴于數據傳輸對象的，因此下層就會出現對上層的依賴了。
所以本人認為DTO是在各層中傳輸數據的，我們可以不必強求的把他們映射到上述層次中，可以把他們放置在一個公共包中。
問題二:使用POJO作業務對象的輕量級架構與上述層模型的映射
在使用POJO的輕量級結構中我們通常會使用持久化框架（如Hibernate/JPA）同時會在架構中引入倉庫對象(Repository Object)，負責業務對象的獲取和保存。（注意：他的功能和DAO是有區別的，倉庫對象中通常只應包括業務對象的獲取和保存邏輯）。
通常設計人員會把業務對象映射至業務層，而將倉庫對象映射至整合層。由于倉庫對象對于業務對象的依賴關系就會破壞依賴關系約束，所以這種映射方式顯然不正確。
下圖是作者推薦的映射方式
圖表 2 輕量級架構參考模型
可以看到業務對象和倉庫對象都被映射至業務層，而持久化框架被映射到了整合層。
總結
因此大家在設計過程中不要僅僅將分層結構留于形式，而要時刻注意設計是否符合這種架構模式，這樣才能真正發揮這種架構模式的優勢。
JavaEE 咨詢顧問
SCEA (1.2&5.0)
IBM Certified Solution Designer for OOA&D UML2