业务设计原则

下面这些内容摘自张开涛的书籍《亿级流量网站架构核心技术》，推荐大家阅读本书。

业务设计原则，主要有：

1. 防重设计
2. 幂等设计
3. 流程可定义
4. 状态与状态机
5. 后台系统操作可反馈
6. 后台系统审批化
7. 文档和注释
8. 备份

防重设计

比如，结算页面要考虑重复提交的问题，还有下单时扣减库存要防止重复扣减的问题。解决方案可以考虑防重key、防重表。而有些场景下如重复支付，是因为有的电商网站同时支持微信支付、京东支付，渠道不一样是无法防止重复支付的。但是在系统设计时，需要将支付的每笔情况记录下来。

幂等设计

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

流程可定义

如果接触过保险业务，就会发现不同保险的理赔服务是不一样的。在设计系统时就设计了一套专门的理赔流程模块。而承保流程和理赔流程是分离的，在需要时进行关联，从而可以复用一些理赔流程，并提供个性化的理赔流程。

状态与状态机

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

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

还要考虑并发状态修改问题，如一个订单同时只能有一个修改；状态变更的有序问题，以及状态变更消息的先到后到的问题，如支付成功消息和用户取消消息的时间差。

后台系统操作可反馈

假如修改了某些内容后想预览看最终效果，这就是希望得到反馈结果；还有就是在规则系统中，希望看到这些规则在系统数据下的反馈。因此，在设计后台系统时，需考虑效果的可预览、可反馈。

后台系统审批化

对于有些重要的后台功能需要设计审批流，比如调整价格，并对操作进行日志记录，从而保证操作可追溯、可审计。

文档和注释

在一个系统发展的初期就应该建立文档库，例如设计架构、设计说明书、业务规则说明书，程序猿在写代码时也应写清楚注释，不然会给其他的程序猿带来理解上的障碍，并严重降低工作效率。

备份

一种是代码备份，代码要提交到代码仓库进行管理和备份。还有一种就是程序猿的备份，我们要确保一个模块，至少有两个程序猿对其是相当熟悉的。