正文
上面这幅流程图是一个简化版本的正向支付流程图，发起支付的时候，用户端需要选择支付渠道，然后根据不同的支付渠道发起对应的支付。支付成功后，再处理订单的支付状态。
每一个支付渠道都有一套独立的支付流程，也就意味着每接入一个支付渠道，这些部分都需要单独开发，工作量和当初一开始做第一个支付的差不多，工期长就难免了。
这还是简化的正向的支付流程，如果考虑订单退款、资金流水管理，那么工作量会更多。
怎么化解这种情况？实际上还是需要产品从业务层面抽象支付过程。
我们梳理一下上面各个支付渠道的过程，发现其实发起支付、支付成功判断和通知订单支付成功这三个环节其实是类似的，因此可以将上面的流程图简化为下面的样子。
中间框起来的那部分就是支付网关要做的事情。这个时候也许会有人质疑，实际上每个支付渠道还是要单独处理一遍，并没有简化什么。从面上看确实是，所以这里就涉及到领域驱动设计的思想了。
领域抽象
回到我们的支付环节，我们可以拆分成三个模块，前台模块、后台的订单模块和支付模块。
这三个模块如果能够在前期通过一种形式进行分离和交互约定，那么当三个模块的某个模块发生变动时，其他两个模块的变动可以降低到极限，从而可以减轻变动带来的系统开发工作量。
我们先来看看如何分离，分离的目的是尽量保证数据的单向流动，比如支付环节的数据流向图如下。
从这幅图我们可以看到，实际上前台模块到支付模块的数据流是可以单向流动的，那么我们约定好不同模块的数据交互规则就可以减少某个模块变动带来的影响了。
下面是三个模块约定的信息：
