后台重构：基于状态机的事件机制

最新推荐文章于 2024-06-25 15:13:06 发布

熊孩子会撒野

最新推荐文章于 2024-06-25 15:13:06 发布

阅读量1.1k

点赞数 1

分类专栏：是时候重构文章标签：架构

本文链接：https://blog.csdn.net/u011692924/article/details/88308943

版权

本文探讨了后台业务重构，采用状态机机制处理数据状态变化，以应对复杂的业务场景。通过状态机表统一管理状态转换，降低代码维护难度。状态机的继承减少了配置数据，使用抽象类实现事件监听，简化了复杂场景的额外操作处理。

摘要由CSDN通过智能技术生成

对于后台业务实现方式的重构，源于目前的业务场景太多太复杂，我们写代码的时候总不免落入“伪面向对象”的方式，以瀑布流的形式一直在原来的业务代码上叠新的代码，创建不同的分支。导致每提一个小需求，就要在各个地方去增加代码，而且还会遗漏，并且代码的质量难以维护。

出于这样的困境，我们想将现在实现的业务场景进行高度抽象和归类，很多业务代码，无非是对数据状态的变更。比如一条数据A，在业务场景A下，只是从状态a翻转成状态b。而在场景B下，除了翻转状态，还会去发一条短信。

场景A：数据A（状态a -> 状态b）

场景B：数据A（1. 状态a -> 状态b  2. 发短信）

所以这里完全用状态机的机制去实现状态翻转的工作，另外再处理额外的功能（比如场景B的发短信）。

状态机的理解是：数据A遇到事件1，会从源状态翻转到目标状态　

数据A： 源状态 --(事件1)--> 目标状态

1. 状态机表

我们用了一张状态机表来存储这种变化关系：

CREATE TABLE `task_status_trans_rule` (
  `ID` bigint(64) NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `TASK_TYPE` varchar(25) DEFAULT NULL COMMENT '任务类型',
  `SRC_STATUS` varchar(15) DEFAULT NULL COMMENT '源状态',
  `DEST_STATUS` varchar(15) DEFAULT NULL COMMENT '目标状态',
  `EVENT_TYPE_NAME` varchar(32) DEFAULT NULL COMMENT '事件类型',
  `REMARK` varchar(50) DEFAULT NULL COMMENT '描述',
  `CREATE_TIME` datetime DEFAULT NULL COMMENT '创建时间',
  `MODIFY_TIME` datetime DEFAULT NULL COMMENT '修改时间',
  PRIMARY KEY (`ID`)