幾乎所有結構良好的軟件都使用了分層設計。分層設計將一個應用程序根據技術職能分為幾 個內聚的部分，從而將某種特定技術或接口的實現細節與其他部分分離開來。分層設計可以用任 何一種強壯的編程語言來實現。圖1-2給出了一個典型的的高級視圖，該 圖對於許多商業應用程序都是有用的。
下圖中的箭頭讀作“依賴於”或“使用”。這種分層設計其實來源於迪米特法則，該法則的一種表述方式就是，“每一層都應該只對那些與自己緊密相關的層有有限的了解。”
每一層都只與自己的直接下層“交互”。這就保證了依賴流（dependency flow)只有一個方向，從而避免了那種在沒有分層設計的應用程序中非常普遍的披薩式的代碼。
MyBatis是一個持久層框架。持久層位於應用程序的業務邏輯層和數據庫之間。這種分離非常重要，它保證了持久化策略不會混入業務邏輯代碼，反之亦然。這種分離的好處就在於你的代碼將更加容易維護，因為它允許對象模型的演化不依賴於數據庫設計。
雖然MyBatis關注的主要是持久層，但理解應用程序的整體架構中的每個層仍然是很重要的。 雖然通過分層設計可以將關注點分離，從而將對任何一種特定實現的依賴都降到最低（甚至沒有)，但如果你認為這樣就可以不管其他層的存在，不顧與其他層的交互，那就太天真了。不論應用程序設計得多么完美，你都必須明白層與層之間一定存在某些間接的行為關聯。以下各節將 討論應用程序的各個層以及MyBatis與這些層的關系。
業務對象模型
業務對象是一個應用程序的所有其他部分的基礎。它是問題域在面向對象方法學中的一種表現，因此構成業務對象模型的各個類有時也被稱為領域類（domain class)。所有其他層都使用業務對象模型來表現數據和執行某些特定的業務邏輯功能。
應用程序的設計者們通常都是從業務對象模型的設計開始的。即使從較高的層次上看，業務對象模型中定義的各個類也都來源於我們的問題域中的名詞。隨着應用程序越來越復雜，類代表更抽象的概念。
業務對象模型類中當然也可能包括一些邏輯，但它們決不能包含任何用於訪問其他層（特別是表現層和持久層）的代碼。此外，這個業務對象模型絕對不能依賴於其他任何一層。其他層可 以使用業務對象模型——但永遠不能反過來。
像MyBatis這樣的持久層通常會使用業務邏輯對象來表現存儲在數據庫中的數據。業務對象模 型中的這些領域類將成為持久化方法（persistence method)的參數和返回值。也正是因為這個原因，這些類有時也被稱為數據傳輸類（data transfer object, DTO)。雖然數據傳輸並不是它們唯 一的作用，但從持久化框架的角度看，這個名字還是相當合適的。
系列文章：