5月 20 2018

走取购项目-订单的删除状态是否单独预留

走取购项目跟其他一般商城一样，对于订单的状态大致可以分为如下几个：
待付款 | 待发货 | 待收货 | 已完成 | 已取消 | 已关闭 | 已删除

在最初的设计中，我把‘已删除’状态跟订单的其他状态一起放入到一个字段(status)中存储。在前期看来好像是没什么问题，
并且该状态的应用场景也很简单，只是针对于前端用户手动删除自己认为可不用显示在订单列表的订单，当然用户发起的这个删除
操作是有前提的，比如某一个订单已经处于在不可逆的生命周期里面（待发货，待收货）是不允许删除的。

因此在符合特定的条件下，用户删除订单后，这张订单对于用户来说是不可见的，而对于后台系统来说，这个状态只是一个逻辑删除（状态标识），管理员仍旧可以查询到该订单，这个很好理解，一个正常的订单系统都应该完整的保存用户生成的每笔订单。

这是之前线上的订单删除逻辑，系统也稳定运行，直到有一天走取购运营人员核对财务账单后，爆出了一个问题!

4月 22 2018

后端开发

走取购项目-关于合并支付的解决方案

之前的一篇文章回顾了「走取购」应对订单拆单的解决方案，但还有一点没有说完，那就是支付的问题。因为我们不免出现以下的情况：

1.多条订单创建完成之后，不可能需要用户分开支付多次，一定是唤起一次支付宝/微信就支付完成；
2.用户可能放弃这次支付，然后又选择了支付其中某一笔订单，或其中订单列表里面待支付的另外两笔；

所以在这样的场景下，订单与支付不可能再像没有合并支付功能那样，属于同一条数据或者一对一关系了。

3月 11 2018

后端开发

走取购项目-思考订单拆单逻辑

在v1.1的版本之前，走取购的订单模块应付的业务场景比较简单，具体表现在所有的商品购买最终只会生成1笔订单，不过随着产品的需求升级，系统需要对接第三方渠道的商品，不仅仅是自营，例如还有网易严选，唯品会等等。

对于新版本的要求，由于商品的来源渠道不同，促销方式和物流等亦不相同，不可能跟之前的版本一样处理成为1笔订单了，自然第一反应想到的肯定是拆单，但具体到方案落实上呢？

为了响应本次需求，我还特意参考了其他主流电商网站的做法，主要是当当，京东。发现它们的需求场景跟我们大致一样，都是同有自营商品之外，另外有其他渠道/入驻店铺的商品，客户端用户则可以自由组合进行统一下单。

而对于拆单的时机，上面的两个网站处理方式就稍显不同了：

2月 2 2018

后端开发

走取购项目-防止库存超卖

之前的一篇文章回顾了「走取购」创建订单时库存的扣减时机。今天再来看看项目对于库存超卖的解决办法。

什么是库存“超卖”？其实简单来讲就是多卖了，库存的数量变成了小于0。为什么会出现这种情况，因为明明在扣减库存的时候会去检查剩余数量，然后再进行减法运算。

是的，明面上看这是没什么问题，似乎挺合理的，看下伪代码：


public Boolean reduceStocks(String goodsId,int number){
	Goods goodsEntity = goodsDAO.findOne(goodsId);
	if(goodsEntity.getStock() >= number){
		goodsDAO.reduceStock(goodsId,number);
		return true;
	}else{
		return false;
	}
}