几乎所有结构良好的软件都使用了分层设计。分层设计将一个应用程序根据技术职能分为几 个内聚的部分，从而将某种特定技术或接口的实现细节与其他部分分离开来。分层设计可以用任 何一种强壮的编程语言来实现。图1-2给出了一个典型的的高级视图，该 图对于许多商业应用程序都是有用的。
下图中的箭头读作“依赖于”或“使用”。这种分层设计其实来源于迪米特法则，该法则的一种表述方式就是，“每一层都应该只对那些与自己紧密相关的层有有限的了解。”
每一层都只与自己的直接下层“交互”。这就保证了依赖流（dependency flow)只有一个方向，从而避免了那种在没有分层设计的应用程序中非常普遍的披萨式的代码。
MyBatis是一个持久层框架。持久层位于应用程序的业务逻辑层和数据库之间。这种分离非常重要，它保证了持久化策略不会混入业务逻辑代码，反之亦然。这种分离的好处就在于你的代码将更加容易维护，因为它允许对象模型的演化不依赖于数据库设计。
虽然MyBatis关注的主要是持久层，但理解应用程序的整体架构中的每个层仍然是很重要的。 虽然通过分层设计可以将关注点分离，从而将对任何一种特定实现的依赖都降到最低（甚至没有)，但如果你认为这样就可以不管其他层的存在，不顾与其他层的交互，那就太天真了。不论应用程序设计得多么完美，你都必须明白层与层之间一定存在某些间接的行为关联。以下各节将 讨论应用程序的各个层以及MyBatis与这些层的关系。
业务对象模型
业务对象是一个应用程序的所有其他部分的基础。它是问题域在面向对象方法学中的一种表现，因此构成业务对象模型的各个类有时也被称为领域类（domain class)。所有其他层都使用业务对象模型来表现数据和执行某些特定的业务逻辑功能。
应用程序的设计者们通常都是从业务对象模型的设计开始的。即使从较高的层次上看，业务对象模型中定义的各个类也都来源于我们的问题域中的名词。随着应用程序越来越复杂，类代表更抽象的概念。
业务对象模型类中当然也可能包括一些逻辑，但它们决不能包含任何用于访问其他层（特别是表现层和持久层）的代码。此外，这个业务对象模型绝对不能依赖于其他任何一层。其他层可 以使用业务对象模型——但永远不能反过来。
像MyBatis这样的持久层通常会使用业务逻辑对象来表现存储在数据库中的数据。业务对象模 型中的这些领域类将成为持久化方法（persistence method)的参数和返回值。也正是因为这个原因，这些类有时也被称为数据传输类（data transfer object, DTO)。虽然数据传输并不是它们唯 一的作用，但从持久化框架的角度看，这个名字还是相当合适的。
系列文章：