分享下我的独立开发日记 02

上文：分享下我的独立开发日记 01 https://www.v2ex.com/t/826537#reply10

已经过去 5 天。

在这 5 天中继续开发，增加了 977 行代码量，删除了 467 行。

这几天主要实现订单的功能，注重劳逸结合，减轻了不少工作量，看了看小说，大脑放松了不少。

之前想的还是太简单了，以为一个订单能有多复杂，虽然之前也实现过，

但考虑一个实现一个功能完善的的 Sass 产品的订单，还真把我累得呕吐，产生心理不适。

在这里，分享一下我对订单的产品设计：

我设计了一个包裹的概念，对应一个快递，一个订单下可以由多个包裹，包裹可以合并或者拆分。

考虑一个用户短时间内下了两个订单，作为卖家肯定要合在一起发货，或者一个订单内多种商品，也可以分拆来发货，比如第一个商品用顺丰，其他商品用申通，那么运费也要重新计算。

一个文件上海寄到杭州，和一个洗衣机寄到内蒙的费用肯定不同。包裹的快递费的计算要结合物品的体积、重量、件数（这个也影响了商品 SKU 的设计）。另外也要考虑不同地区的费用。如内蒙、内蒙不发货。这种逻辑不能让卖家写在商品说明里面就完事，要让用户下单的时候就自动解决这些问题。

营销的活动包括免邮、满减、满折，营销的设计不能过于粗暴，比如 A 商品的利润比较高，我可以单独对 A 商品做营销活动，买 A 商品减 20 元，买其他商品不减。另外营销的对象也要考虑，比如首单用户、vip 用户还有活动的生效时间段等

这些费用的计算不能是糊涂账，每一个优惠，每一笔费用都要单独记录，用户退款的时候，这些数据都有用

解决超卖的问题并不难，但要考虑这事一个 saas 产品，也许有的商家就允许超卖呢？所以我在设计商品的时候，加了一个是否超卖的设计。

允许超卖：不严格控制库存，库存可为负数。不允许超卖：设计库存扣除的阶段，加购物车减库存、订单支付减库存、库存不足则订单失败。

100 个订单，估计有 20%的退单，退单包含 1. 部分商品退 2. 只退款不退货 3 只退货不退款因为有各种活动，这时候退单的金额就比较复杂了，又因为退单对接的是支付宝、腾讯的退单接口，这时候也要加一个手动控制，这种交易做成完全自动化的，风险很大。

除了以上的大功能。还考虑了订单的追踪功能、订单的改价、订单的操作（如无货了，后天直接关闭订单，退款）

再来个同样的收尾：

本来预期半个月能收尾，看来还是乐观了，订单已经完成 70%左右，争取年底前把订单完全做好。