前言
开发后端项目时，我们最常见的一种架构模式就是分层架构 。
所谓的分层架构，就是把系统自上而下分为多个不同的层，每一层都有特定的功能和职责，且只和自己的直接上层与直接下层 “打交道”。
分层架构的优点是：每一层都有明确定义的职责，易于理解和维护；而且各层可以独立扩展，以适应不同的需求。
所以分层架构也是最适合新手入门学习、并且实际开发中应用最多的架构。
分层架构
下面给大家一种 Java 企业级后端项目开发时常用的分层架构，一般从前端界面（表示层）发送的请求出发，需要经历接入层、控制层、业务逻辑层、通用业务层、数据访问层、系统资源层等。
-
表示层 通常是指让用户交互和查看信息的前端界面，比如用户点击按钮后能够发送一个请求，也可以叫用户层、界面层等。
-
发送请求后，会经过 接入层 ，比如 Nginx 网关、或者其他中间件，对请求做一个预处理或转发，比如实现负载均衡。这一层不是必须存在的，通常更适用于中大型项目，前端也可以直接请求后端。
-
接入层会将请求转发到 控制层（Controller），负责接受请求、调用业务逻辑层（Service）的代码实现功能、然后响应结果。控制层一般不建议写复杂的业务逻辑，尽量保持精简。
接下来是 业务逻辑层（Service），负责处理复杂的业务逻辑，比如对请求数据进行校验、处理、调用数据访问层以将结果存到数据库中等，也是我们做系统时主要开发编码的部分。
通用业务层（Manager、Module）是一种特殊的业务逻辑层，主要的作用是抽取了一些需要被多个业务调用的公共代码，比如上传文件到对象存储、鉴权等，从而实现复用。 -
数据访问层（Dao / Mapper）负责操作底层的数据源，比如对数据库、文件、缓存等进行增删改查。
-
最后是 系统资源层 ，也可以叫基础设施层，包括各种基础服务、系统环境等，比如数据库、消息队列、Redis、文件存储、Linux 系统、Docker 等。复杂的基础设施可能还包括 K8S 容器资源编排、资源调度平台等。
需要注意的是，并不是所有的分层架构都需要这么划分，不同业务和团队可能有自己的分层选择与规范。
项目实践
比如我带大家开发的 OJ 在线判题系统 ，分层架构如下：
示例项目结构
基于分层架构，我们可以将项目按照特定的目录名（包名）来组织代码，比如：
- controller：控制层
- service：业务逻辑层
- mapper：数据访问层
- model：数据模型
还可以按照业务或文件的类型来划分目录，比如：
- constant：常量
- annotation：注解类
- common：公共类
- config：配置类
- job：任务
- exception：异常处理相关
- utils：工具类
以之前带大家做过的为例，项目的目录结构如图：
其他知识
-
计算机网络也是采用了经典的分层架构，OSI 七层参考模型中，把计算机网络自底向上分为了物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。每个层只处理特定的功能，比如数据传输、数据的路由；层与层之间通过接口（或者叫协议）进行通信。
-
需要注意的是，我们常用的后端开发框架 Spring MVC 是基于 MVC（Model-View-Controller）设计模式构建的，而不能算是传统的分层架构。而且一般现在的项目中只使用 Spring MVC 作为整个项目的控制层，不过大多数用了 Spring MVC 框架的项目基本都使用了分层架构。