背景
租户之间业务代码耦合度太高
。虽然租户之间大多业务场景类似,但也有不同,用if-else判断租户进行不同的业务逻辑处理。 增加测试成本,某一租户的业务逻辑需要修改,同时使用到这一段代码的所有租户都需要进行测试。 service臃肿,一个 service 1000
多行代码,包含了所有租户的业务逻辑,不利于后续维护和扩展。
重新梳理设计
在DDD领域驱动设计中,
负责处理业务基本规则的是领域层,而不是应用层
,我们可以借鉴这种思想,把各个租户的业务逻辑内聚在各自的租户下,做到各个租户之前代码的相互隔离,互不影响。根据依赖倒置原则,
抽象不应该依赖细节,细节应该依赖抽象
,对于一些租户公共的业务逻辑行为,提取为抽象类,具体的细节差异由各个租户各自实现。工厂模式
,根据不同的租户拿到对应的租户对象,进行对应的业务处理逻辑。
重构代码示例
controller
@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工厂实现
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));
}
}
service
业务逻辑主要分布在了AbstractOrderAction
、AOrderAction
与BOrderAction
三个类中,AbstractOrderAction
也500多行代码,各自租户之间完成了解耦,更利于后续的维护和扩展。总结
这种设计并不适用于业务场景复杂且过多的场景。
❝其中OrderAction顶层接口中包含了所有业务行为,如果业务一旦复杂过多,会导致AbstractOrderAction抽象类过度臃肿,进而又形成了一个1000多行的'service',只能再度进行拆分重构。总之根据项目业务的体量做最合适的设计。
没有最好的,只有最合适的,最合适的也就是最好的
如喜欢本文,请点击右上角,把文章分享到朋友圈
如有想了解学习的技术点,请留言给若飞安排分享
因公众号更改推送规则,请点“在看”并加“星标”第一时间获取精彩技术分享
·END·
相关阅读:
一张图看懂微服务架构路线 基于Spring Cloud的微服务架构分析 微服务等于Spring Cloud?了解微服务架构和框架 如何构建基于 DDD 领域驱动的微服务? 微服务架构实施原理详解 微服务的简介和技术栈 微服务场景下的数据一致性解决方案 设计一个容错的微服务架构
作者:super凹凸曼
来源:juejin.cn/post/7336751931375779892
版权申明:内容来源网络,仅供学习研究,版权归原创者所有。如有侵权烦请告知,我们会立即删除并表示歉意。谢谢!
我们都是架构师!
关注架构师(JiaGouX),添加“星标”
获取每天技术干货,一起成为牛逼架构师
技术群请加若飞:1321113940 进架构师群
投稿、合作、版权等邮箱:admin@137x.com