谈一谈购物车

如题：今天谈一谈购物车这个话题。
最近在重构购物车，因此借着兴头谈一谈购物车的设计。
好久好久之前，那个时候还有没有智能手机，尚未京东，淘宝也刚刚起步，大概是在上学时读书看到的，记得书中说购物车是放在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等，这些冗余考虑也是为了谨慎，
在没彻底想好如何兼容老系统，如何作出完美的设计前，也不敢冒然不冗余。

 

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