分层架构是常用的架构模式，对于一个大系统可以划分为几个子系统，各子系统位于不同的抽象层次。各层间上层依赖下层服务，下层不能依赖上层。

消息可以从上向下，也可以从下向上。自顶向下调用下层接口，称为请求。自低向上的通信，称为通知，一般使用回调方法，从而实现单路径耦合。

【分层的步骤】

1、定义抽象准则

2、根据准则定义抽象层数

3、给每个层命名并指定任务

4、指定服务

5、细化分层，重复上述步骤，直到一个稳定的分层结构

6、为每层指定接口

7、构建独立层

8、指定层间通信，分离临接层

9、设计错误处理策略

【分层的变体】

松散分层结构：注重性能，损失可维护性

继承分层结构：访问直接，依赖性强

【分层的优点】

分层架构模式是个可靠的通用模式，对于大部分应用它是个很好的开始，尤其当不知道哪种结构适合使用时。

它有如下几点优势：重用性好、标准化支持、局部依赖、可替换性

【分层的缺点】

分层主要有以下的缺点：影响多层次的修改；降低了效率；多层传递，重复的工作；层的粒度难以把握。

分层的多层传递中有现象被称为污水池反模式（architecture sinkhole anti-pattern）。该反模式描述的是这样的场景，请求流穿过架构的很多层，每一层只有少量的甚至没有业务逻辑。例如，假设展示层响应用户的请求获取客户信息，展示层将请求传递给业务层，业务层什么也不做，仅仅将请求直接传递给持久层，持久层执行SQL语句获取数据。数据在回传过程中没有经过任何的处理。

每个分层架构都可能会有一些场景落入污水池反模式。然而关键是分析这样的请求占了多少比例。通常80-20定律可用来分析是否落入了污水池反模式。当反模式的比例比较大时，你或许考虑将某些层开放，这时要注意缺乏层隔离，会使得以后修改时比较困难。

分层架构会使应用变得庞大，即使把表示层和业务层分成了单独的部署单元。这对某些应用不需要考虑，但是也会带来一些部署的隐患，如健壮性、可靠性、性能和可伸缩性。

【常用分层】

三层模型：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。

四层模型：表示层，应用逻辑层，领域模型层，数据库层