记一次多租户项目的后端代码重构优化

1、背景

分享一次代码优化的案例,一个多租户项目,基于数据库字段进行租户隔离,多租户之间用的同一个后端服务,使用MVC架构,在经过数次迭代之后,逐渐发现该项目已存在严重问题:租户之间业务代码耦合度太高。

  1. 虽然租户之间大多业务场景类似,但也有不同,用if-else判断租户进行不同的业务逻辑处理。
  2. 增加测试成本,某一租户的业务逻辑需要修改,同时使用到这一段代码的所有租户都需要进行测试。
  3. service臃肿,一个service 1000多行代码,包含了所有租户的业务逻辑,不利于后续维护和扩展。

2、重新梳理设计

  1. 在DDD领域驱动设计中,负责处理业务基本规则的是领域层,而不是应用层,我们可以借鉴这种思想,把各个租户的业务逻辑内聚在各自的租户下,做到各个租户之前代码的相互隔离,互不影响。
  2. 根据依赖倒置原则,抽象不应该依赖细节,细节应该依赖抽象,对于一些租户公共的业务逻辑行为,提取为抽象类,具体的细节差异由各个租户各自实现。
  3. 工厂模式,根据不同的租户拿到对应的租户对象,进行对应的业务处理逻辑。

3、重构代码示例

controller

java 复制代码
@PostMapping("/infoByNamePage")
@ApiOperation(value = "分页查询", notes = "分页查询")
public R<Page<OrderInfoPageVO>> infoByNamePage(@Valid @RequestBody OrderInfoVoRequest orderInfoVoRequest) {
    OrderAction orderAction = OrderFactory.getOrderAction(CurrentUserUtil.getTenantId());
    return orderAction.infoByNamePage(orderInfoVoRequest);
}

其中OrderAction是顶层接口,拥有租户所有的业务行为

OrderFactory工厂实现

java 复制代码
public class OrderFactory implements ApplicationContextAware {
    // 租户A
    private static final String ORDER_TENANT_A = "A";
    // 租户B
    private static final String ORDER_TENANT_B = "B";

    @Autowired
    private OrderTenantConfig config;

    private static Map<String, OrderAction> orderActionMap = new HashMap<>(2);

    /**
     * 根据租户id获取对应租户
     **/
    public static OrderAction getOrderAction(String tenantId) {
       OrderAction orderAction = orderActionMap.get(tenantId);
       if (ObjectUtil.isEmpty(orderAction)){
          throw new OrderBusinessException(OrderCodeEnum.TENANT_ID_IS_NULL);
       }
       return orderAction;
    }

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
       // AOrderAction、BOrderAction 两个租户各自的实现类
       orderActionMap.put(config.getMap().get(ORDER_TENANT_A), applicationContext.getBean(AOrderAction.class));
       orderActionMap.put(config.getMap().get(ORDER_TENANT_B), applicationContext.getBean(BOrderAction.class));
    }
}

重构之后,1000多行的service业务逻辑主要分布在了AbstractOrderAction、AOrderAction与BOrderAction三个类中,AbstractOrderAction也500多行代码,各自租户之间完成了解耦,更利于后续的维护和扩展。

4、思考与总结

这种设计并不适用于业务场景复杂且过多的场景

其中OrderAction顶层接口中包含了所有业务行为,如果业务一旦复杂过多,会导致AbstractOrderAction抽象类过度臃肿,进而又形成了一个1000多行的'service',只能再度进行拆分重构。总之根据项目业务的体量做最合适的设计。没有最好的,只有最合适的,最合适的也就是最好的

若有错误,还望批评指正

相关推荐
码熔burning4 分钟前
JVM 对象创建的核心流程!
java·jvm
努力努力再努力wz8 分钟前
【C++进阶系列】:万字详解红黑树(附模拟实现的源码)
java·linux·运维·c语言·开发语言·c++
毕设源码纪师姐8 分钟前
计算机毕设 java 高校机房综合管控系统 基于 SSM+Vue 的高校机房管理平台 Java+MySQL 的设备与预约全流程系统
java·mysql·课程设计
渣哥22 分钟前
HashMap 扩容为啥总是 2 的倍数?一场来自底层的“强迫症”探险
java
叫我阿柒啊1 小时前
从Java全栈到前端框架的实战之路
java·数据库·微服务·typescript·前端框架·vue3·springboot
wu~9701 小时前
开发思路篇:转账接口设计
java·开发语言
IT乐手1 小时前
Java 实现异步转同步的方法
java
杨杨杨大侠1 小时前
附录 1:🚀 Maven Central 发布完整指南:从零到成功部署
java·github·maven
青草地溪水旁2 小时前
23 种设计模式
开发语言·c++·设计模式
渣哥2 小时前
Java HashMap 扩容机制详解:触发条件与实现原理
java