分层架构是最通用的架构，也称为多层架构模式。实际上分层架构是Java EE应用中最广泛使用的架构。
模式描述
分层架构模式将组件组织为水平多层，每个层负责应用的特定角色（例如：展示逻辑或业务逻辑）。尽管分层架构模式并没有指定层的数量，但是一般有标准的四层：展示层，业务，持久化和数据库。在一些场景下，业务层和持久层使用一个业务层组成，尤其当持久化层被嵌入到业务层时。对于小型应用可能只有三层，而大型或负责的业务应用可能包含五层或者更多。
应用中的每一层都有一个特定的角色和职责。例如：展示层负责用户界面和与浏览器通信逻辑，业务层负责执行业务请求职责。每一层只关注自己的业务请求。例如：展示层不需要知道或关心怎么样获取用户数据；它只需要在屏幕上展示用户数据即可。与此类似，业务层不需要关心怎么样格式化展示用户数据或者如何获取用户数据，它只需要将持久层的数据获取到，然后对数据进行业务逻辑操作，然后将数据传递到展示层。
1-1 经典四层分层架构模式
分层架构模式的强大特性之一是：通过层将关注点分离。特定层只处理与该层有关的逻辑。例如：展示层只处理展示逻辑，业务层只处理业务逻辑。这种组件分类使得容易的构建角色和职责到你的架构中，并且使得应用更容易开发，测试，管理和维护（主要是因为组件接口和范围的界限明确）。
关键概念
每一层是对修改关闭的。这是分层架构模式重要的概念。层关闭意味着请求从一层到另一层，请求必须通过一层才能进入下一层。例如：请求源自展示层，则该请求必须经过业务层，然后到达持久化层，最后才能到达数据库层。如下图：
1-2 层关闭
所以，为什么不允许展示层直接访问持久化层或者数据库层？毕竟从展示层直接访问持久化层比通过业务逻辑层更快。原因就是层隔离。
层隔离意味着一个层的改变不影响其它层：改变对其他层或者关联层是隔离的。如果你允许展示层直接访问持久化层，那么持久化的的SQL变更可能会影响业务逻辑层和展示层，因此应用程序之间多个层是耦合的。这样将会导致应用难以或者修改的代价很大。
层隔离也意味着，每一层对其他层是独立的，因此，层与层之间并不知道其内部的实现流程。为了更好的理解层隔离的重要和强大，举个例子：
假设需要对工程进行展示层的重构：从JSP转换到JSF。假设展示层和业务层依然使用相同的模型，那么展示层的重构将不影响业务层。
由于层封闭便于层隔离，因此有助于隔离架构内的变化，但是有时候某些层开放是有必须要的。比如工具类，审计日志和日志类。
例如：在业务层下加入一个新的服务层，如果在层关闭的前提下，那么业务层必须经过这个新层才能访问持久化层，这样做可能没有什么意义。这是分层架构的一个老问题，可以通过创建一个开放的层来解决这个问题。开放的层意味着上层不一定需要经过这层，而可以直接访问开放层以下的层，例如：业务逻辑层可以直接访问持久化层而不必经过开放层。如下图所示：
1-3 层开放
层开放和封闭概念有助于我们架构层的关系和请求处理流程，有助于开发和设计人员理解架构中各层的访问限制。
模式举例
下图展示了分层架构的流程，获取用户的个人信息和订单数据，黑线及箭头代表请求，红色虚线代表响应：
1-4 模式距离
对Java而言，一般展示层是JSP或者JSF，业务层是spring 的Bean，数据访问对象是Mybatis，JDBC或者Hibernate等。
思考
分层架构是一个比较通用的架构模式，尤其是当你不知道该使用哪种架构时，你可以选择使用分层架构。但是依然需要注意以下几点:
1 架构坑-反模式 请求经过的层可能没有或者只有很少的业务逻辑。
2 单体应用 某一层需要升级，则需要停掉整个服务。
模式分析
敏捷性：低
敏捷性是能够快速响应不断变化的需求。分层架构模式可以通过层隔离来适应变化，但是层与层多之间依然是紧耦合的。
易于部署： 低
是否易于部署依赖于你对分层架构的实现。对大型应用而言，一个层的小改动可能就需要重新发布整个应用，导致发布需要大量的时间进行计划，排程；同时会增加发布的频率。
测试性：高
测试某一层时可以将其依赖的层进行打桩，所以分层架构可测试性比较高。
性能：低
由于一个请求需要经过多层才能满足业务需求，所以导致性能不高。
可扩展性：低
由于分层架构模式的层与层之间耦合，所以一个修改可能涉及多层。
易于开发：高
实现分层架构技术难度低，而且能够满足大部分应用开发的需求。
