订单创建后数据准备应该放在什么时候执行？

订单的创建一般都会包含金额支付的业务场景，而金额的支付的业务场景我这里分为了线下、线上两种支付方式。线下的支付方式包括现金支付，充值消费；线上则是微信，支付宝，银联，paypal，银行卡支付等等此类。

线下的支付是程序的执行方式是顺序执行，数据的处理逻辑是一个独立的整体；而线上的支付则基本分为三步：

1、下单

先在订单系统中创建一个等待支付的订单，获取订单信息。

2、支付

根据订单信息，调用支付三方的接口或SDK生成支付所需数据，以二维码或其他方式让用户发生在线支付。

3、等待回调

在第二步请求前，或请求中传递的参数中带有了，三方支付回调时调用的本系统服务接口的地址，在此接口中，进行验证回调数据的正确性，订单状态的修改，以及后续订单开通的服务。

至此，订单支付算是基本完成。但是用户购买完订单相应的服务（日用商品除外）后，要享受或使用该服务时，该服务的享受记录，或是否已享受的数据该什么时候写入呢，这个是个思考的问题。

第一种思考：

创建订单时就做记录，这个有点不太合理，创建订单时，用户并没有付费，就有了记录，业务严谨性有问题，PASS。

第二种思考：

订单支付完成后马上做记录，这个还行，但是要分两种情况处理，因支付方式不同，线下支付是在支付完成后顺序在程序中增加处理； 而线上支付则要在回调接口中增加处理。或者封装到服务开通中进行统一处理。这个时候新增的数据都是待使用的状态，等待用户使用服务时更新状态即可。这个方案在用户使用服务时响应很快，但是在下单时，可能因为下单修改的数据太多而影响到下单支付的响应速度。各有利弊，具体看业务场景中的下单涉及的数据量多少。

第三种思考：

订单支付完成后不做新增，当用户使用服务时新增服务使用记录数据，这种方案把整个服务分为了购买和售后两块来做，业务上比较清晰明了，数据上处理起来也算独立吧，这个方案不错，可以对于下单时涉及修改数据太多而造成响应慢的情况，做此方案执行，可能会提高一定效率，而用户使用服务时，因数据量也就一个数据，响应也不可能太慢的。

 

综上所述，订单创建后的数据准备应该是在用户使用服务时写入，而不是提前写入。

 

后话：我使用第二种思考来做是为了后续查看服务的使用情况时好查找，而使用第三种思考时要多绕一道弯来做查询，显得有点麻烦，但是第三方思考的方案他数据准确啊，依据订单查询的结果，数据全面且准确，后续可适用于多个业务场景。