电商交易场景状态机方案探索及应用

背景

目前闲鱼行业产品有回收、寄卖、验货宝等，这些产品在基础交易模式上引入附加玩法规则，其状态机相比于普通交易模型更加灵活复杂。基础交易模型订单状态只包含：创建订单->付款->发货->确认收货 。以回收举例，在中台基础交易模型之上，又附加了诸多行业业务状态，如服务商收货、质检、用户确认质检等。这些状态，是通过用户或服务商等多种角色推进的，而业务状态的维护也需要闲鱼自己来负责。

存在问题

目前，在状态履约的代码逻辑实现上，状态履约方法内使用IF-ELSE的结构来判断不同履约动作。在不同的分支里，根据推进节点的不同，存在不同的参数校验、业务执行等等操作。这种原始的实现方式，随着业务的不断发展，逐步暴露出以下问题：

1. 1. 代码接口复杂：目前回收业务推进某一个单一状态的代码就已经达到上百行，如果把整个状态拓扑的所有履约逻辑都写到一起的话，则整个履约方法将达到上千行，代码内聚高、可读性差。

2. 2. 模板式代码冗余、无复用：如前置校验、后置消息等。

3. 3. 无整体拓扑视图：回收场景的这一套代码完成后，之后的开发、服务商、测试都不能感知整体的一个拓扑逻辑。现在我们只能使用另外准备的拓扑图去作为解释文档，但代码上是没有能力直接把整个拓扑提取出来的。

4. 4. 可扩展性差：如果要增加状态或者删除状态，或者是增加一条履约的边。那么开发人员都需要去改if-else。并且开发改起来的时候必须非常的小心谨慎。比如说要加一个状态，那首先需要整体增加一个else代码块。另外，在每一个之前IF-ELSE分支里面又需要加上判断逻辑，单独处理新加的状态是否可以做迁移等等，所以扩展性是极差的。

此外，横向来看，在行业交易的不同产品下，还存在许多共性需求：

• • 状态拓扑查询：在服务商接入、测试回归等场景，都需要查询当前业务的状态拓扑，以知道当前订单允许推进到哪些状态。目前只能依靠另外编写对接文档的方式进行沟通。代码没有直接提取状态的能力，有可能导致了对接文档的滞后性。

• • 状态履约执行：在实际线上履约、对接联调、代码开发、测试回归场景中，都需要执行状态的履约。另外࿰