1、背景
分享一次代码优化的案例，一个多租户项目，基于数据库字段进行租户隔离，多租户之间用的同一个后端服务，使用MVC架构，在经过数次迭代之后，逐渐发现该项目已存在严重问题：租户之间业务代码耦合度太高。
- 虽然租户之间大多业务场景类似，但也有不同，用if-else判断租户进行不同的业务逻辑处理。
- 增加测试成本，某一租户的业务逻辑需要修改，同时使用到这一段代码的所有租户都需要进行测试。
- service臃肿，一个service 1000多行代码，包含了所有租户的业务逻辑，不利于后续维护和扩展。
2、重新梳理设计
- 在DDD领域驱动设计中，
负责处理业务基本规则的是领域层，而不是应用层，我们可以借鉴这种思想，把各个租户的业务逻辑内聚在各自的租户下，做到各个租户之前代码的相互隔离，互不影响。 - 根据依赖倒置原则，
抽象不应该依赖细节，细节应该依赖抽象，对于一些租户公共的业务逻辑行为，提取为抽象类，具体的细节差异由各个租户各自实现。 工厂模式，根据不同的租户拿到对应的租户对象，进行对应的业务处理逻辑。
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'，只能再度进行拆分重构。总之根据项目业务的体量做最合适的设计。
没有最好的，只有最合适的，最合适的也就是最好的
若有错误，还望批评指正