本篇我们将讨论分层架构模式。
分层架构模式是一种n层模式，其中组件按照水平层次进行组织。这是设计大多数软件的传统方法，旨在实现自我独立。这意味着所有组件之间相互连接，但彼此之间不相互依赖。
这种架构模式有四个层，每个层中的模块性和组件之间都有连接。从上到下，它们分别是：
展示层：包含与展示相关的所有类别。
业务层：它包含业务逻辑。
持久层：用于处理对象关系映射等功能
数据库层：存储所有数据。
在这种情况下，各层是封闭的，也就是说请求必须从顶部到底部经过所有层。这样设计有两个原因，一个是将所有"相似"的组件放在一起，另一个原因是提供层次的隔离。
进一步说明，将“相似”的组件放在一起意味着与某个层相关的所有内容都保留在该单一层中。这样可以清晰地区分各种组件，并且有助于将相似的代码集中在一个位置。通过隔离各层，它们相互之间变得独立。因此，例如，如果我们想将数据库从Oracle服务器更改为SQL服务器，这将对数据库层产生重大影响，但不会影响其他层。同样，假设您有一个自定义的业务层，并且想要将其更改为业务规则引擎，如果我们有一个良好定义的分层架构，这种更改不会影响其他层。
分层架构模式可以在所提及的层级之外进行修改，增加其他层级。这被称为混合分层架构。例如，在业务层和持久化层之间可以添加一个服务层。然而，这并不是理想的设计，因为现在业务层必须经过服务层才能到达持久化层。这个请求通过服务层并没有任何价值。我们称之为架构陷阱反模式。请求经过各层时，在每个层中几乎没有或没有执行任何逻辑。
唯一解决这个问题的方法是将可选的层级设置为开放层。这意味着如果可选的层级对发送的请求有任何增值作用，请求就会经过该层级。如果没有增值作用，请求将直接绕过该层级，进入相关的下一层级。在上图中可以看到这种情况，请求绕过了服务层，从业务层直接进入持久化层。
然而需要注意的是，通过设置开放层，我们削弱了层级之间独立的好处。如果我们想替换持久化层，就必须考虑到开放的服务层和业务层。这两个层级现在都与持久化层耦合在一起。因此，虽然向系统中添加开放层非常容易，但我们不允许这种情况发生。我们必须在不损害架构的情况下解决问题。
结论
分层架构是最简单的软件架构模式。如果要设计一个基本的应用程序，用户数量很少（<100-200），并且在投入使用后不会有太多的需求变化，那么这是最好的软件架构模式。与其他模式相比，这种架构模式的实现成本非常低。
以下是分层架构模式的优劣分析。
优点
这种架构模式易于测试，因为组件属于特定的层级。因此，它们可以单独测试。
由于大多数应用程序自然而然地按层级工作，所以这种架构模式简单易实现。
缺点
尽管可以对特定层进行更改，但这并不容易，因为应用程序是一个单一的单元。而且，层之间的耦合关系往往会增加难度。这也使得扩展变得困难。
它必须作为一个单一的单元部署，因此对特定层的更改意味着整个系统必须重新部署。
它的规模越大，请求经过多个层级所需的资源就越多，从而导致性能问题。
