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

转自：代码这件大事

背景：

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

1. 又加需求，一个方法本来就处理了 300 行，现在又加 50 行。

2. 状态逻辑太多了，产品第 2 期又加了一个逻辑，代码结构要调整，很头疼。

3. 每个人都在吐槽，业务研发在工作中处理最多的就是 if else，好不容易写个 switch 都能给同事吹一周。以上三个场景应该是日常需求迭代优化中面临最多的场景了，作为一个自称编码水平较高的人，总结了以下三个真实的场景，给出一些可选的方案。

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

核心

实际例子

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

1. 发短信

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

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

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

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

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

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

1. 各种商品订单（天猫，淘宝，外卖）

2. 工作流（审批，工单处理）

这类需求的特点是，读写场景QPS不高，对数据的准确一致性要求非常高。我们底层一般直接存储到数据库，之上加一层简单的数据缓存就能处理。

面临的主要问题是，状态太多难以维护，应该还会出现状态的调整比如特殊场景下的状态A到状态Z的扭转。 

不过业内早已给出了比较通用的解决方案，有限状态机。下面我们列举一个简单的订单状态扭转逻辑：

n元组的概念其实早已经渗透到了开发中的每一个角落，我们需要做的事情就是，在业务开发的时候真正的去思考这一层数据模型，然后加以运用，最后的代码一定不那么 if else。

总结

以上三板斧在业务中使用可以很轻，也可以很重。这就意味着我们能自己写一个简单够用的（对于你完全了解成长有限的业务场景），或者找一个star多且在维护的开源方案（对于有潜力，未来大有可为的业务）来代替。同时，这些编码套路在各种场景下都能非常灵活的组合，比如：

1. 订单状态更新后触发事件（状态机+事件订阅）

2. 不同业务线，状态机配置，初始化放松不同（n元组+状态机）

不得不提到的一点，在漫长的业务迭代中，产品文档会越来越缺失，最终只有通过代码才能了解线上的真正逻辑（有时间代码过于复杂，可能就没有人知道线上的具体情况了），集中配置，统一维护的意义之一就在于此。相信做过复杂历史系统的交接或重构的同学对这一点都深有体会。

参考

[有限状态机](https://zh.wikipedia.org/zh-hans/%E6%9C%89%E9%99%90%E7%8A%B6%E6%80%81%E6%9C%BA)

[go fsm](https://github.com/looplab/fsm)

热文推荐

Spring Boot 与微服务从0到1的实践

我在外包公司做增删改查有前途么/p>

那天晚上和@FeignClient注解的深度交流