业务的设计原则

防重设计

结算页需要考虑重复提交，还有如下单扣减库存的时候，防止重复扣减库存，解决方案可以考虑防重key,防重表，而有些场景的重复支付是无法避免的，比如现在有些电商网站同时支持支付宝和微信以及其他支付方式，这种情况，可以在系统设计时候，将每笔交易情况记录下来，以便退款的时候可回溯

幂等设计

交易系统中，经常会用到消息，而现有的消息中间件基本不保证发生重复消息的消息，因此，需要业务系统在重复消息消费时进行幂等处理，在使用第三方支付时，第三方支付会进行异步回调，也要考虑做好回调的幂等处理

状态与状态机

设计交易订单系统时，会存在正向状态(待付款，待发货，已发货，完成)和逆向状态(取消，退款)等，正向状态和逆向状态应该根据系统的特征来决定要不要分离存储。状态设计时应该有状态轨迹，方便用户跟踪当前订单的轨迹并记录相关日志，万一出问题可回溯

另外，还有订单状态的变迁，比如待支付、已支付待发货、待收货、完成的迁移。要考虑要不要使用状态机来驱动状态的变更和后续流程节点操作，尤其当状态很多的时候，使用状态机能更好地控制状态迁移。

还要考虑并发状态的修改问题，如一个订单同时只能有一个修改，状态变更的有序问题，以及状态变更消息的先到后到问题，

后台系统操作可反馈

很多场景都需要反馈，比如，修改了某些内容后，想预览看下最终效果，即想得到一些反馈，还有一些是在规则系统中，希望看到这些规则在系统数据下的反馈，因此在设计后台系统的时候，需要考虑效果可预览、可反馈。

后台系统审批化

对于有些重要的后台功能需要设计审批，比如调整价格，广告的上架，推广审核

备份

备份包括代码备份和人员备份。代码主要是提交到代码仓库进行管理和备份，代码仓库至少具备多版本的功能。人员备份指的是一个系统至少应该有两名开发人员是了解情况的，即使其中一个离职了，也不会出现新人接手之后手忙脚乱的情况，对于有些核心人员写的代码，被认为是不可替代的，这种情况，让他带一名兄弟一起开发核心代码