今天尹白和大家一起分析商城项目中的创建订单的业务.通过这次对商城服务的核心业务中的创建订单的分析和解刨,对商城的订单有一个全面的认识.
在商城业务当中,创建订单的接口,可以说是整个商城的业务当中最重要的接口。通过创建订单,真正建立了一个商品与用户的联系。之所以说真正建立,是因为有人或许也会说,添加购物车也是商品和用户之间建立联系,但是那种联系太弱,还没有让用户认识到,这个商品会属于我,所以我不认为购物车那不是真正的联系。那么言归正传,创建订单这个接口,到底涉及到哪些业务呢?
首先,我们从创建订单的结果分析一下。
从创建订单的结果上来看,有几张重要的表,我们来列举一下。
第一张表是订单表orderInfo。订单表入库内容: 新增订单表1条数据,订单数据中包含几个方面。订单数据中包含的用户信息:有用户id, 用户手机号, 用户openId, 当前小程序appid等;包哈的总购买信息有:商品的总金额, 邮费总金额,订单总金额, 商品总积分, 邮费总积分,订单总积分, 积分抵扣金额,礼券抵扣金额, 订单应付金额, 订单应付积分等;关于订单信息字段有:订单超时过期时间等;还有物流信息有:收件人,收件地址,收件人手机号等,以及使用礼券的场景:礼券id字段,还有是否使用积分抵现字段等,这些是订单表的入库信息。总的来说是几个方面,订单的信息,用户的信息,物流的信息,礼券和积分信息。
第二张表是新增订单商品表n条数据,也就是订单详情表,或者叫订单商品表orderGoods。 订单商品表需要新增的字段有订单id, 商品信息快照, 当前商品的购买信息,字段有商品总金额, 商品总积分, 邮费总金额, 邮费总积分, 积分抵扣金额, 礼券抵扣金额,商品应付金额, 商品应付积分。这张表有一特别需要注意的是,商品信息快照。因为商品信息快照要记录购买当时的商品信息,尤其是购买时的价格,积分。既然是快照,那记录的就当然是那个时刻的商品信息。如果有一天,商家把商品的价格提高了,给用户展示订单时,不能去查当前的商品价格,而是给展示购买时的快照价格。
第三商品主表goods表修改数据: 商品销量值。这个值对应的还有每个商品sku的销量,毕竟维护商品库存的,是实实在在的sku,所有还要修改goods_sku表的值.
第四库存goods_stock表修改数据: 库存值的冻结,当然,不同的系统对于库存的管理不一样,可能和店铺有关系,比如做了店铺的库存管理的,关于库存自然还有专门的一套逻辑,这里以最简单的一个goods_stock概述,不一一举场景,毕竟这次重点不是库存。
第五订单日志表order_log新增一条日志: 用户下单日志, 用户信息字段, 订单id,时间, 订单状态等。
第六使用了积分的场景, 积分账户表修改: 冻结积分值加, 减可用积分值。
第七使用了礼券的场景, 礼券表修改: 冻结用户的礼券。
这以上的内容是分析创建订单的结果,我们总结的内容,需要我们修改的,新增的信息。那么,有了具体的结果,接下来我们就要分析一下,如何组织出这些结果呢?
其次,我们从组织字段来分析一下。
组织字段时,我们要分析,哪些是需要计算得出来的字段,哪些是需要查询出来的字段,这些字段用怎样的数据结构进行组织。组织字段的时候,我们可以用一个上下文变量,把组织好的字段以及需要使用的对象放在这个上下文变量中,方便后面的业务直接取出来使用。下面我们来分析一下。
第一,我么要计算商品总金额,邮费的总金额,积分抵现的金额,礼券抵现的总金额,邮费的分摊金额和积分等,这些都是我们要计算的。这些计算,我们需要的是sku商品的价格,商品的邮费的数值,每增加一份商品的邮费附加值等等。如果物流方面做的更完善,我们还需要对物流的具体邮费,根据用户的邮寄地址,进行计算。
第二,库存的冻结和销量的增加。
第三,积分抵扣,礼券抵扣,抵扣金额的分摊。
第四,如果购买的是礼券,对所购买的礼券的库存进行冻结。
组织字段我们就说这些,最重要的是,组织的时候要调理清晰,步步为营。
最后,我们来分析一下,组织信息前,我们需要做哪些校验。
其实校验这个步骤,在代码里是写在最前面的,但是在我们分析代码逻辑里,是放在最后分析的,实际写代码的时候也可以放到最后再写。因为是根据组织字段的需求,我们对入参以及中间对象的状态数据的校验。下面我们来分析一下。
第一, 用户: 购买资格,如是否冻结账户。
第二, 商品: 商品是否上架, 库存是否充足等。
第三, 积分: 是否充足。
第四,礼券: 是否有该礼券。
这些校验都是基础的,具体需要在组织字段的过程中出来。
当然,对商城项目的业务分析的创建订单的分析除了这些,还有很多,比如创建订单成功之后,我们需要返给客户端的信息,这些接口定义好的交互信息也是我们需要考虑好的,基本上可以从上下文变量中都拿到。例如需要创建订单后调起微信支付的信息等。还有就是,关于订单超时的处理,比如发送订单超时的延时队列。再有就是发送一些对用户的通知,比如推送短信通知或者公众号模板消息等。
以上就是对商城项目中创建订单的分析,通过这个分析,我们可以更好的把握创建订单的流程。
今天我们聊一聊商城项目的业务中关于缓存的使用。在前面的内容中,我们已经介绍过商城业务中的核心接口,创建订单,https://www.inbai.net/article/141.html,在这篇文章里,我们详细介绍了创建订单的流程,不过我们更多的讨论的是业务分析,而没有深入去研究创建订单的性能。那么,今天我们就关于商城项目的性能方面,展开我们的话题,也就是在合适的地方使用上合适的缓存机制。
今天我们分析一下,商城项目的业务中,必不可少的支付环节,现在主流的微信支付,几乎是每一个商城项目都必备的支付方式,我们来分析一下微信支付的业务。项目中的支付,一般都会独立成一个模块,很多时候会独立成一个服务。因为调用支付的业务线一般都有好几条,比如商城下单后支付订单,比如商城购买高级会员或者续费,比如saas服务中购买某个插件或者某些功能等等。这些业务都会用到支付,没必要把支付放到商城模块下,更好的做法是把支付抽离出来,和各个模块形成松耦合。
今天尹白和大家一起分析商城项目中的创建订单的业务.通过这次对商城服务的核心业务中的创建订单的分析和解刨,对商城的订单有一个全面的认识。在商城业务当中,创建订单的接口,可以说是整个商城的业务当中最重要的接口。通过创建订单,真正建立了一个商品与用户的联系。