履约流程设计

今天了由于需要修改一部分履约逻辑，顺便阅读了订单履约处理流程。

先介绍下业务背景，我们有很多种不同的下单业务类型，比如电台，直播，实物等，它们的履约需求是有很大的差异性的。在我们的履约逻辑设计中，同事抽取了通用流程部分和个性化处理部分。整体逻辑比较清晰明了，下面我们一起来了解下如何应对这种多业务类型，多处理流程的设计方式。

通用处理部分是什么

设计一个系统时，如何提升系统的可扩展性，这是我们需要考虑的一个重点。首先我们需要对业务流程进行分析建模，了解目前业务和未来业务的特点。然后根据业务特点进行抽象和封装。抽象和封装有一个重要的任务就是提取共同点，我们来看下履约流程的共同点有哪些：

1. 请求拦截处理，异常处理，幂等处理
2. 由订单状态变更触发业务逻辑
3. 处理失败数据重试及监控

这三个共同点也是很多系统的通用共同点。

第一点常见的处理方式是注解切面，通用逻辑处理可以放在around切面中，前置处理，后置处理，异常流程我们均可插入自己的处理逻辑。
另一种处理方式即通过抽象类，模版模式来实现。效果也是类似的。相比切面，此方法的规范性更强。结合泛型，适配性也很好。

第二点业务处理，在我印象中，责任链几乎是一个万能的模式，集合了设计模式原则大部分的优点，在履约代码里，我们将一个个处理单元分割成一个个node，放到一个list集合中依次执行，这其实是责任链的一种变形。我们在很多开源中能见到各种各样的责任链变形，在代码解耦合方面效果很好。

第三点，处理失败数据重试及监控，这从架构上来讲，可以划分到第一点。之所以单独拆开，主要原因是这块业务的共性是我们很多人所忽视的，在技术上也是需要考虑抽象和解耦的。如消息队列或DB异步任务。

总结下我们通用部分流程，可以用如下图来说明：

个性化处理部分

这里涉及内容的其实是template下面的node,根据单一职责原则，一个node处理自己负责的功能点。这里的业务逻辑就不做详细介绍了。

总结

这里的通用模式内容适合大部分流程型的业务处理，可以看作是策略模式和责任链模式的结合。
不同业务间的处理根据不同业务type对应不同的template，这是策略模式的应用，只是没用strategy这一名称。node同理，为责任链的一种变形。