分层架构是常用的架构模式，对于一个大系统可以划分为几个子系统，各子系统位于不同的抽象层次。各层间上层依赖下层服务，下层不能依赖上层。
消息可以从上向下，也可以从下向上。自顶向下调用下层接口，称为请求。自低向上的通信，称为通知，一般使用回调方法，从而实现单路径耦合。
【分层的步骤】
1、定义抽象准则
2、根据准则定义抽象层数
3、给每个层命名并指定任务
4、指定服务
5、细化分层，重复上述步骤，直到一个稳定的分层结构
6、为每层指定接口
7、构建独立层
8、指定层间通信，分离临接层
9、设计错误处理策略
【分层的变体】
松散分层结构：注重性能，损失可维护性
继承分层结构：访问直接，依赖性强
【分层的优点】
分层架构模式是个可靠的通用模式，对于大部分应用它是个很好的开始，尤其当不知道哪种结构适合使用时。
它有如下几点优势：重用性好、标准化支持、局部依赖、可替换性
【分层的缺点】
分层主要有以下的缺点：影响多层次的修改；降低了效率；多层传递，重复的工作；层的粒度难以把握。
分层的多层传递中有现象被称为污水池反模式（architecture sinkhole anti-pattern）。该反模式描述的是这样的场景，请求流穿过架构的很多层，每一层只有少量的甚至没有业务逻辑。例如，假设展示层响应用户的请求获取客户信息，展示层将请求传递给业务层，业务层什么也不做，仅仅将请求直接传递给持久层，持久层执行SQL语句获取数据。数据在回传过程中没有经过任何的处理。
每个分层架构都可能会有一些场景落入污水池反模式。然而关键是分析这样的请求占了多少比例。通常80-20定律可用来分析是否落入了污水池反模式。当反模式的比例比较大时，你或许考虑将某些层开放，这时要注意缺乏层隔离，会使得以后修改时比较困难。
分层架构会使应用变得庞大，即使把表示层和业务层分成了单独的部署单元。这对某些应用不需要考虑，但是也会带来一些部署的隐患，如健壮性、可靠性、性能和可伸缩性。
【常用分层】
三层模型：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。
四层模型：表示层，应用逻辑层，领域模型层，数据库层