购物车架构
类关系图
说明
CartController 购物车控制器
CartService 购物车服务接口
CartServiceImpl 购物车服务实现类
FreightTemplateService 运费模版服务
EsGoodsSearchService es中的商品搜索服务
MemberCouponService 会员优惠券服务
GoodsSkuService 商品服务
PromotionGoodsService 促销服务
购物车操作流程图
加入购物车
1、请求加入购物车，携带skuid，数量，活动id等等
2、服务端从缓存中获取最新商品（缓存中不存在时，会有缓存击穿处理，重新获取对象放入缓存中）
3、商品服务返回最新商品信息
4、为购物车中的商品填充促销信息，且根据活动id选择默认活动（将最新购物车更新进入到缓存中）
5、返回给前台加入购物车结果
更新购物车
6、请求更新购物车，携带skuid，更新后的数量
7、服务端从缓存中获取最新商品（缓存中不存在时，会有缓存击穿处理，重新获取对象放入缓存中）
8、商品服务返回最新商品信息
9、为购物车中的商品填充促销信息，且根据活动id选择默认活动（将最新购物车更新进入到缓存中）
10、返回给前台更新购物车结果
获取购物车
11、请求获取购物车信息
12、服务端返回从缓存中记录的购物车信息
清空购物车
13、请求清空购物车
14、服务端清楚redis中的购物车记录
15、返回购物车清除结果
额外说明
购物车是用户访问的高频接口，在这块设计中，几乎所有的操作都是根据缓存中的信息进行，这样可以在用户高频访问下，有效减少服务端计算的压力。在这块逻辑中，促销模块则借用mongodb来实现，由于促销关系是多对多的关系，所以存入redis中之后，进行查找是一件很痛苦的事情，所以在架构这块逻辑时，综合评定，最后还是决定用mongo作为这块的中间件，经过压测，效果良好。
购物车类关系图
类关系图 - TradeDTO的构成
- PromotionGoods 数据库DO，为商品的促销活动描述，包含开始结束时间，库存，分类店铺id，价格，优惠价格等信息
- CartSkuVO 即sku在购物车中的VO
- CartVO 购物车VO，在此处抽象为一个店铺，后续订单流程中会被抽象称为一个订单，一个购物车有多个店铺商品时会抽象为多个订单，CartVO即后边流程中的订单原型
- PriceDetailDTO 价格详情，包含各个维度的费用与展示，平台分佣、店铺运营成本等等所有的信息都会记录在这里
- PriceDetailVO 价格描述VO，用于讲一些字段描述称为前端需要展示的字段
- ReceiptVO 发票信息
- memberCouponDTO 会员选中的优惠券
- OrderVO 在后续交易信息生成时，通过CartVO生成的对象
- TradeDTO 正比交易，在本系统中，一笔交易可以理解为一次下单，在订单构建器中，TradeDTO将作为数据基础，一步步构建出交易的原型，一笔交易包含本次交易中所有订单信息的总和，包括支付信息，商品信息，优惠信息等等
购物车类型说明
public enum CartTypeEnum {
/**
* 购物车
*/
CART,
/**
* 立即购买
*/
BUY_NOW,
/**
* 拼团
*/
PINTUAN,
/**
* 积分
*/
POINTS,
}
说明
- 普通购物车，即加入购物车的类型，代表购物车，长时间有效，随时可以更新购物车信息
- 立即购买，即跳过购物车页面间断，也不会将普通购物车已经勾选的商品带入结算页，可以快速下单操作
- 拼团，类似立即购买功能，增加拼团信息的描述
- 积分，独立于其他购物车，用于积分兑换场景
架构思路
目前 购物车信息全部都存储与redis中，页面的交互携带购物车类型进行传递，渲染内容，让结算页面可以展示不同的信息，来满足各个场景的不同需求。
- 为购物车增加类型，首先可以服用价格渲染部分代码，否则有多个购物车实体类，传入对象不一致，就需要不同的代码来进行购物车的渲染了
- 购物车类型字段在后端只存在于缓存中，前端只存在于页面跳转携带的参数中。整体架构这样设计让前后端都可以实现充分的复用，而且用户在使用中也不会觉得突兀，各种购物车的结算页面也不会有区别，用户对系统的习惯不需要适应。