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

文章目录

  • [一. 如何分层](#一. 如何分层)
    • [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 小时前
智慧城市建设方案
大数据·架构·智慧城市·制造
鲁班大叔_0072 小时前
使用扣子与Dify的业务风险
架构·产品
hello早上好2 小时前
Spring不同类型的ApplicationContext的创建方式
java·后端·架构
Python智慧行囊3 小时前
Python 中 Django 中间件:原理、方法与实战应用
python·中间件·架构·django·开发
HyggeBest3 小时前
Mysql的数据存储结构
后端·架构
冰橙子id4 小时前
centos7编译安装LNMP架构
mysql·nginx·架构·centos·php
喵叔哟4 小时前
25.【.NET8 实战--孢子记账--从单体到微服务--转向微服务】--单体转微服务--用户服务接口
微服务·架构·.net
WindrunnerMax9 小时前
从零实现富文本编辑器#5-编辑器选区模型的状态结构表达
前端·架构·github
hstar95279 小时前
三十五、面向对象底层逻辑-Spring MVC中AbstractXlsxStreamingView的设计
java·后端·spring·设计模式·架构·mvc
大模型之路10 小时前
基于本地LLM与MCP架构构建AI智能体全指南
人工智能·架构