业务逻辑开发套路的三板斧

RryLee 的个人博客 / 1174 / 2 / 创建于 4年前 / 更新于 4年前 / 2 个改进

背景：

作为一个研发，我们工作中都会处理面临下面这些困惑：

又加需求，一个方法本来就处理了 300 行，现在又加 50 行。
状态逻辑太多了，产品第 2 期又加了一个逻辑，代码结构要调整，很头疼。
每个人都在吐槽，业务研发在工作中处理最多的就是 if else，好不容易写个 switch 都能给同事吹一周。
以上三个场景应该是日常需求迭代优化中面临最多的场景了，作为一个自称编码水平较高的人，总结了以下三个真实的场景，给出一些可选的方案。

第一板斧：抽象事件，驱动业务

核心

梳理产品逻辑中的主流程节点，整理节点所需要的依赖数据以及节点触发后对应的业务逻辑。
类比消息队列，也是不同的业务方订阅自己的事件源，进行不同的处理。不同点在于一个是分布式，一个是本文描述单机业务处理场景。

实际例子

举一个用户注册之后的场景，需要：

发短信
发优惠券
如果用户注册成功之后，直接发了mq消息，那么用户系统和券系统分别订阅这个消息进行处理。不过这里讨论的是在一个项目模块中处理完所有相关的逻辑。

代码将在 UserRegistered() 中一步一步去处理逻辑，之后需求又加入了 初始化A数据和初始化B数据 两个需求，实现也会落到这个方法之后，最后整个代码会越来越臃肿。

业务逻辑开发套路的三板斧

接下来用事件订阅模型去化解这个点，非常实用，一点都不华丽，代码也很好读懂。

最后对应到程序代码可能是这样的：

# 事件注册
Event::register(UserRegistered::class, [
    SendSms::class,
    SendCoupon::class,
    InitSystemA::class,
    InitSystemB::class,
]);

# 业务调用
handleRegistered($user) {
    $event = new UserRegistered($user);
    $event->fire();
}

后面的迭代维护中，只要主流程不发生变化，那么相应的逻辑只需要去增加订阅者去实现。

业务逻辑开发套路的三板斧

第二板斧：有限状态机，定义流程

在业务逻辑数据处理这一层，很多的业务场景都与数据扭转状态有关，并且最后会有相应的数据实体相映射。比如我们常见的：

各种商品订单（天猫，淘宝，外卖）
工作流（审批，工单处理）

这类需求的特点是，读写场景 QPS 不高，对数据的准确一致性要求非常高。我们底层一般直接存储到数据库，之上加一层简单的数据缓存就能处理。
面临的主要问题是，状态太多难以维护，应该还会出现状态的调整比如特殊场景下的状态A到状态Z的扭转。
不过业内早已给出了比较通用的解决方案，有限状态机。下面我们列举一个简单的订单状态扭转逻辑：

业务逻辑开发套路的三板斧

fsm := fsm.NewFSM(
    "created",
    fsm.Events{
        {Name: "pay", Src: []string{"created"}, Dst: "paid"},  //支付
        {Name: "cancel", Src: []string{"created"}, Dst: "closed"}, //关闭
    },
    fsm.Callbacks{
        "after_pay": func(e *fsm.Event) { /* 支付成功调用 */ },
    },
)

如果涉及到状态相关的调整，在状态机定义的地方去修改就可以解决问题。
和事件订阅非常相似，也是集中维护，同一管理。