【架构】后端项目如何分层及分层领域模型简化

文章目录

  • [一. 如何分层](#一. 如何分层)
    • [1. 阿里规范](#1. 阿里规范)
    • [2. 具体案例分析](#2. 具体案例分析)
  • [二. 分层领域模型的转换](#二. 分层领域模型的转换)
    • [1. 阿里规范](#1. 阿里规范)
    • [2. 模型种类简化分析](#2. 模型种类简化分析)
  • [三. 小结](#三. 小结)

本文描述后端项目中如何进行分层,以及分层领域模型简化

一. 如何分层

1. 阿里规范

阿里的编码规范中约束分层逻辑如下:

  1. 开放接口层:可直接封装 Service 方法暴露成 RPC 接口
  • 通过 Web 封装成 http 接口;
  • 进行网关安全控制、流量控制等。
  1. Service 层: 相对具体的业务逻辑服务层,一般不可复用

  2. Manager层: 通用业务处理层,它有如下特征:

  • 对第三方平台封装的层,预处理返回结果及转化异常信息;
  • 对Service层通用能力的下沉,如缓存方案、中间件通用处理;
  • 与DAO层交互,对多个DAO的组合复用。
  1. DAO 层: 数据访问层,与底层 MySQL、Oracle、Hbase 进行数据交互。

2. 具体案例分析

下面介绍一下具体业务中应该如何实现分层。

rpc框架选用的是thrift作用和controller层类似

分层描述

  1. 最上层controller和TService是我们阿里分层规范里面的第一层:轻业务逻辑,参数校验,异常兜底。通常这种接口可以轻易更换接口类型,所以业务逻辑必须要轻,一般不做具体逻辑(接口可抽离给其他client调用)。

    如果业务逻辑过多的放到controller层,当接口开放成rpc接口时,controller的逻辑需要复制一遍。所以我们需要把业务编排逻辑都得放进service中去做。

  2. Service:业务层,复用性较低,这里推荐每一个controller方法都得对应一个service,不要把业务编排放在controller中去做。

  3. Mannager(或者我们说的commons层):可复用逻辑层。 这里的Mannager可以是单个服务的,比如我们的cache,mq等等,当然也可以是复合的,当你需要调用多个Mannager的时候,这个可以合为一个Mannager,比如逻辑上的连表查询等。如果是httpMannager或rpcMannager需要在这一层做一些数据转换

  4. DAO:数据库访问层。 主要负责"操作数据库的某张表,映射到某个java对象",dao应该只允许自己的Service访问,其他Service要访问我的数据必须通过对应的Service

二. 分层领域模型的转换

1. 阿里规范

在阿里巴巴编码规约中列举了下面几个领域模型规约:

  • DO(Data Object):与数据库表结构一一对应,通过DAO层向上传输数据源对象。
  • DTO(Data Transfer Object):数据传输对象,Service或Manager向外传输的对象。
  • BO(Business Object):业务对象。由Service层输出的封装业务逻辑的对象。
  • AO(Application Object):应用对象。在Web层与Service层之间抽象的复用对象模型,极为贴近展示层,复用度不高。
  • VO(View Object):显示层对象,通常是Web向模板渲染引擎层传输的对象。
  • Query:数据查询对象,各层接收上层的查询请求。注意超过2个参数的查询封装,禁止使用Map类来传输。

领域模型对应到各个分层

序号 层次 领域模型
1 Controller/TService VO/DTO
2 Service/Manager AO/BO
3 DAO DO

2. 模型种类简化分析

如上阿里规范中,每一个层基本都自己对应的领域模型,在一次请求中,一个对象可能在不同层中出现3-4次转换,返回的时候同样也会出现3-4次转换,这样在一次完整的请求-返回会出现很多次对象转换。如果这么设计模型,不光会产生资源浪费,而且会增加开发复杂度。

所以这里提出如下模型种类简化逻辑:

  1. 允许Service/Manager可以操作数据领域模型,对于这个层级来说,本来自己做的工作也是做的是业务逻辑处理和数据组装。
  2. Controller/TService层的领域模型不允许传入DAO层,这样就不符合职责划分了。
  3. 同理,不允许DAO层的数据传入到Controller/TService。

三. 小结

  1. 业务分层对于代码规范是比较重要,决定着以后的代码是否可复用,是否职责清晰,边界清晰。
  2. 当然这种分层其实见仁见智,总的来说只要满足职责逻辑清晰,后续维护容易,就是好的分层。

参考:

https://juejin.cn/post/6844903636334542856

相关推荐
小蜗牛慢慢爬行1 小时前
如何在 Spring Boot 微服务中设置和管理多个数据库
java·数据库·spring boot·后端·微服务·架构·hibernate
小扳4 小时前
微服务篇-深入了解 MinIO 文件服务器(你还在使用阿里云 0SS 对象存储图片服务?教你使用 MinIO 文件服务器:实现从部署到具体使用)
java·服务器·分布式·微服务·云原生·架构
盛派网络小助手12 小时前
微信 SDK 更新 Sample,NCF 文档和模板更新,更多更新日志,欢迎解锁
开发语言·人工智能·后端·架构·c#
快乐非自愿16 小时前
分布式系统架构2:服务发现
架构·服务发现
2401_8543910816 小时前
SSM 架构中 JAVA 网络直播带货查询系统设计与 JSP 有效实现方法
java·开发语言·架构
264玫瑰资源库16 小时前
从零开始C++棋牌游戏开发之第二篇:初识 C++ 游戏开发的基本架构
开发语言·c++·架构
神一样的老师16 小时前
面向高精度网络的时间同步安全管理架构
网络·安全·架构
2401_8570262316 小时前
基于 SSM 架构的 JAVA 网络直播带货查询系统设计与 JSP 实践成果
java·开发语言·架构
9527华安16 小时前
FPGA实现MIPI转FPD-Link车载同轴视频传输方案,基于IMX327+FPD953架构,提供工程源码和技术支持
fpga开发·架构·mipi·imx327·fpd-link·fpd953
DT辰白16 小时前
如何解决基于 Redis 的网关鉴权导致的 RESTful API 拦截问题?
后端·微服务·架构