谈一谈购物车

如题：今天谈一谈购物车这个话题。
最近在重构购物车，所以借着兴头谈一谈购物车的设计。
很久很久以前，那个时候还有没有智能手机，还没有京东，淘宝也刚刚起步，大概是在上学时读书看到的，记得书中说购物车是放在session中的，
一同放进session中的还有用户的信息，然后这个印象这个梗一直深埋心中，始终认为购物车，用户信息是放在session中。
后来因为多年不做电商，所以这个梗在你心中一直没有变过，直到近一年多，才发现原来已经过时很久。
现在APP的应用，大数据，分布式技术和一致性协议的开始成熟，session信息和购物车信息开始往持久化方向发展，对那种老古董的架构和设计都是一种冲击。

如果你不懂历史，恭喜你，你站在了技术前沿，学习新生的事物，没有历史的包袱和思维定式，你一定前途无量。
如果你和我一样，从一个遥远的时代过来，那么同样恭喜你，你看到了历史的变迁。
技术的飞速发展，促使你得不断的逼迫自己学习新的事物，相信你的积淀能使你在不断的学习中更加得心应手，对亘古不变的设计运用的炉火纯青，是任何人都无法代替的。

今天要谈购物车我就是站在这样的一个时代变迁的和系统重构的时间点上，基于现在我们现有的系统谈一谈我们的购物车。为什么为什么为什么要重构购物车。
这个问题说起来就又是一个不长不短，不大不小，不痛不痒的历史问题。

上边说过了，现在的session信息，购物车信息，越来越趋向于持久化。
我们先不说这个持久化是放在客户端，比如APP上， 网页cookie中，还是放在服务器redis或mysql,oracel，或其他什么数据库中，我们说一说购物车的数据结构的问题。
无论你是放在哪里存储或者还是放在session中，购物车一定有自己的一个数据结构。
今天我们主要就谈一谈这个数据结构。为什么要谈这个数据结构，因为我认为在这样一个急功急利的时代，能看到的东西才能吸引人的眼球，才能引起人的注意，
用到程序上说着属于测试驱动开发模型，从测试开始倒推，该怎么开发，开发什么，完成一步倒推一步，直到达到递归的结束，开发完成。
我们把这个思想运用到我们的购物车构建上。
那么我们的购物车是什么样子呢，现成的参考模型，淘宝，京东，当当，等等。
然后我们来看，购物车里的有商品，商品有价格，有数量，商品很有可能参加各种活动，各种活动会影响商品的价格。
用户还可以使用优惠券和积分，商品中还有礼品，商品还来自不同的仓库，对于像淘宝，天猫，京东这样的电商有商家入驻，商品还可以来自不同的商家。
这样看购物车里的商品在形成订单时是一定要拆分成不同的订单，就算是同一个仓库，不分商家，但是我前边的文章也说过像保税仓，香港仓也是需要拆分的。
这个可以在购车时不考虑，但是我们一定需要知道。因为既然有这些，我们非常需要按照这些对购物车里的商品进行分组。
所以这部分是非常值得思考和仔细设计的。

我们不防这样按实际的情况想一想，一个商家店铺或者仓库卖东西，举行或者不举行促销活动，卖商品。
按照这样的一个思路想下来，我们的购物车大概是可以这样分类的，首先购物车然后仓库或者店铺，然后促销活动，然后商品。
大概的树形结构下来应该是：
ShoppingCart
　　Store
　　　　Activity
　　　　　　Product
这样想的一个结构应该是能满足很多的使用情况的，比如：
[京东自营]
　　[活动无，没有活动当然可以不显示活动名字]
　　长白山矿泉水一箱 一箱 20元
　　崂山白花蛇草水一箱 一箱 56元
[羊之意店铺]
　　[满100减30]
　　铝膜车衣一件 一件 59元
　　洗车水枪一支，赠送3米水管 一支 38元
[马克华菲官方旗舰店]
　　[买2赠1]
　　白色L号T恤 1件 88元
　　黑色L号T恤 1件 108元
　　[赠品]蓝色L号T恤 1件 0元
这样子是应该能满足购物车的需求的，然后购物车商品选择完毕后，
进入结算页面，在结算页面可以选择是不是使用优惠券，减免券之类的，积分之类的，同时计算出需不需要支付邮费。
最后确认，计算最终的价格，使用完优惠券，积分，邮费，等所有的金额，落库，让用户支付。

这就是我想到的一个购物车的结构了，有同事仔细查看过京东的和淘宝的结果，基本大体的设计是一样的，当然会有差别，但整体思路是一样的。
我想这些都是成熟的设计和结构，不会逃出设计人员的法眼。

结算确认后直接支付或者先生成订单，之后再支付，这个淘宝和京东的处理行为是不一样，
他们的不一样在于如果用户同时在一单内购买了不同店铺的商品，先不支付之后再支付，淘宝是可以分开支付的，而京东是不能分开支付的，
淘宝在生成订单时制直接拆分是不同的两个或多个订单，而京东只有在支付后才显示两个或多个不同的订单。
我想他们不一样可能各自有各自的考量和理由。

在接下来就要谈支付和拆单了，支付的问题我在之前谈过一个，拆单的问题以后在谈。
今天最后的一点时间在说一说，购物车持久化时数据库的存储设计。
我之前的文章说过商城活动的设计，结合活动的设计，大概购物车的设计也是不用存活动的信息的，
活动信息因为和时间关系比较紧密，实时查询可能效果更好，活动信息可以放内存或缓存中查询起来会很快，不用担心时间效率问题。
那么购物车的信息可能就是如下这样:
shoppingcart(
int id pk,
int user_id,

int goods_id,
string warehouse_code,

string sku_code,
string sku_name,
string img_url,
numberic price,
int number,

timestamp create_time,
timestamp update_time
boolean selected
)
大概是这个样子，可以看到这里有一些反设计模式的地方，比如有些冗余的信息，对goods_id, warehouse_code等，这些冗余考虑也是为了谨慎，
在没完全想好如何兼容老系统，如何做出完美的设计前，也不敢冒然不冗余。

 

欢迎网友讨论指正，一起探讨，给予指导，不吝赐教。