分层体系结构模式是n层模式，其中组件被组织在水平层中。这是设计大多数软件的传统方法，并且具有独立性。这意味着所有组件都是互连的，但彼此之间不依赖。
图1：分层架构
在此体系结构中有四层，其中每一层在模块和其中的组件之间都有联系。从上到下分别是：
表示层：它包含与表示层相关的所有类别。
业务层：包含业务逻辑。
持久层：用于处理对象关系映射之类的功能
数据库层：这是所有数据的存储位置。
在这种情况下，层是关闭的，这意味着请求必须从上到下遍历所有层。这样做有两个原因，一个是所有“相似”组件都在一起，另一个是它提供了隔离层。
详细地说，将“相似”的组件放在一起意味着与某个层相关的所有内容都停留在该单个层中。这样一来，就可以在组件的类型之间进行清晰的分隔，并且还可以将类似的编程代码集中在一个位置。通过隔离各层，它们变得彼此独立。因此，例如，如果我们要将数据库从Oracle服务器更改为SQL服务器，这将对数据库层产生很大的影响，但不会影响其他任何层。同样，假设您有一个自定义的书面业务层，并想为业务规则引擎进行更改。如果我们拥有定义良好的分层体系结构，则更改不会影响其他层。
图2：分层架构中的数据传播
可以对分层体系结构模式进行修改，以在提到的层之外增加其他层。这称为混合分层体系结构。例如，在业务层和持久层之间可以有一个服务层。但是，这不是理想的方案，因为现在业务层必须经过服务层才能到达持久层。通过服务层，此请求不会获得任何价值。我们将其称为架构漏洞反模式。请求通过层，而在每个层中执行的逻辑很少或没有逻辑。
图3：分层架构模式中的开放层
解决此问题的唯一方法是将可选层设置为开放层。这意味着，如果可选层将任何值添加到正在发送的请求中，那么请求将通过它。如果不是，那么它将简单地绕过该层，然后转到相关层。从上图中可以看出，请求绕过了服务层，并从业务层移到了持久层。
但是请注意，通过使用开放层，可以消除使用隔离层的好处。如果要交换持久层，则必须考虑开放服务层以及业务层。这两个层现在都耦合到持久层。因此，尽管很容易向系统中添加开放层，但不应允许它发生。我们必须设法解决问题而不损害体系结构。
结论
分层架构是软件架构模式的最简单形式。如果您要设计一个基本的应用程序，其中用户数量很少（<100–200），并且您确定上线后不会有太多的需求变更，那么这是最好的软件架构模式。与其他模式相比，此体系结构模式的实现成本非常低。
以下是分层架构模式的利弊分析。
优点
由于组件属于特定层，因此易于测试。因此，它们可以单独进行测试。
它很容易实现，因为自然而然，大多数应用程序都是分层工作的。
缺点
尽管可以对特定的层进行更改，但这并不容易，因为应用程序是单个单元。而且，层之间的耦合趋于使其变硬。这也使得难以扩展。
必须将其部署为单个单元，因此更改为特定层意味着必须重新部署整个系统。
它越大，请求通过多个层所需的资源就越多，因此将导致性能问题。
