【架构】后端项目经典分层架构介绍

前言

开发后端项目时,我们最常见的一种架构模式就是分层架构 。

所谓的分层架构,就是把系统自上而下分为多个不同的层,每一层都有特定的功能和职责,且只和自己的直接上层与直接下层 “打交道”。

分层架构的优点是:每一层都有明确定义的职责,易于理解和维护;而且各层可以独立扩展,以适应不同的需求。

所以分层架构也是最适合新手入门学习、并且实际开发中应用最多的架构。

分层架构

下面给大家一种 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:工具类

以之前带大家做过的为例,项目的目录结构如图:
在这里插入图片描述

其他知识

  1. 计算机网络也是采用了经典的分层架构,OSI 七层参考模型中,把计算机网络自底向上分为了物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。每个层只处理特定的功能,比如数据传输、数据的路由;层与层之间通过接口(或者叫协议)进行通信。

  2. 需要注意的是,我们常用的后端开发框架 Spring MVC 是基于 MVC(Model-View-Controller)设计模式构建的,而不能算是传统的分层架构。而且一般现在的项目中只使用 Spring MVC 作为整个项目的控制层,不过大多数用了 Spring MVC 框架的项目基本都使用了分层架构。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>