支付逻辑

本来写好一篇了，可惜javaeye这几天不知道整什么，硬是把最后一篇日志弄丢了。

 

  最近部门在做支付分离，正好也画了个自己理解的模型。主要理念应该还是解耦：

1.将不重要的事情，剥离出主要路径，简化主流程响应时间。通过异步处理、模块划分来解耦复杂逻辑，耗时操作。

2. 模块的明晰划分。以后无论扩展促销方式还是支付中的规则限制，均无需伤筋动骨的联调。

做了这样的划分后，商品模块关心打标志位区分各类信息，提供打标志的商家UI操作；各促销模块独立具备发放、使用、退单等流程，记录操作流水。 支付中心则关心一切业务限制逻辑(比如n个商品支持红包，订单最多使用2个红包，每个红包2块钱。。。)，负责完成整个支付流程的事物，写最终订单流水日志。 

 

这里小模块都是有独立事务的，最后被订单在外围调用，是一些“嵌套”的事务。 因此在不可靠环境下，可能外围支付中心事务失败，内部小事务却成功。因此各模块最终状态还需要依赖支付中心订单状态记录。类似“回调”的概念。