订单系统:从0到1设计思路

32 评论 97868 浏览 571 收藏 18 分钟

文章主要跟大家分享在订单系统承载的角色,以及梳理了主要功能的设计思路,一起来文中看看~

概述

本文主要讲述了在传统电商企业中,订单系统应承载的角色,就订单系统所包含的主要功能模块梳理了设计思路,并对订单系统未来的发展做了一些思考。

1. 订单系统在企业中的角色

在搭建企业订单系统之前,需要先梳理企业整体业务系统之间的关系和订单系统上下游关系,只有划分清业务系统边界,才能确定订单系统的职责与功能,进而保证各系统之间高效简洁的工作。

2. 订单系统与各业务系统的关系

(1)对外系统:

所有给企业外部用户使用的系统都在这一层,包括官网、普通用户使用的C端,还包括给商户使用的商家后台和在各个销售渠道进行分销的系统,比如与银行信用卡中心合作、微信合作在合作商的平台露出本企业的产品。这类系统站在与客户接触的最前线,是公司实现商业模式的桥头堡。

(2)管理中后台:

每个C端的业务形态都会有一个对应的系统模块,如负责管理平台交易的订单系统,管理优惠信息的促销系统,管理平台所有产品的产品系统,以及管理所有对外系统显示内容的内容系统等。

(3)公共服务系统:

随着企业的发展,信息化建设到达一定程度后,企业需要将通用功能服务化、平台化,以保证应用架构的合理性,提升服务效率。这类系统主要给其他应用系统提供基础服务能力支持。

3. 订单系统上下游关系

由此可见,订单系统对上接收用户信息,将用户信息转化为产品订单,同时管理并跟踪订单信息和数据,承载了公司整个交易线的重要对客环节。对下则衔接产品系统、促销系统、仓储系统、会员系统、支付系统等,对整个电商平台起着承上启下的作用。

5. 订单系统的业务架构

(1)订单服务

该模块的主要功能是用户日常使用的服务和页面,主要有订单列表、订单详情、在线下单等,还包括为公共业务模块提供的多维度订单数据服务。

(2)订单逻辑

订单系统的核心,起着至关重要的作用,在订单系统负责管理订单创建、订单支付、订单生产、订单确认、订单完成、取消订单等订单流程。还涉及到复杂的订单状态规则、订单金额计算规则以及增减库存规则等。在4节核心功能设计中会重点来说。

(3)底层服务

信息化建设达到一定程度的企业,一般会将公司公共服务模块化,比如:产品,会构建对应的产品系统,代码、数据库,接口等相对独立。但是,这也带来了一个问题,比如:订单创建的场景下需要获取的信息分散在各个系统。

如果需要从各个公共服务系统调用:一是会花费大量时间,二是代码的维护成本非常高。因此,订单系统接入所需的公共服务模块接口,在订单系统即可完成对接公共系统的服务。

订单系统核心功能

1. 订单中所包含的内容信息

为了使订单系统能够对订单进行高效、精准的管理和跟踪,订单会储存关于产品、优惠、用户、支付信息等一系列的订单实时数据,来和下游系统,如:促销、仓储、物流进行交互。

以一个通用B2C商城的订单为例,梳理其包含的信息如下:

这里要注意的是订单类型,随着平台业务的不断发展,品类丰富、交易方式丰富后,需要对订单进行多维度的分类管理,同时订单类型利于订单系统的扩展性。每种订单类型将会对应一套流程及一套状态,便于对订单进行分类管理和复用。

2. 流程引擎

流程是指从平台角度出发,将订单从创建到完成的整个流转过程进行抽象,从而行程了一套标准流程规则。而不同的产品类型或交易类型在系统中的流程会千差万别,因此为了方便对订单流程进行管理,会组建流程引擎模块。

每套订单流程中会包含正向流程及逆向流程,正向流程可以比作一次顺利的网购体验过程中,后台系统之间的信息流转。逆向流程则是修改订单、取消订单、退款、退货等各种动作引起的后台系统流程,同时每个流程触发的条件又可分为系统触发和人工触发两种场景。

(1)正向流程

以一个通用B2C商城的订单系统为例,根据其实际业务场景,其订单流程可抽象为5大步骤:订单创建>订单支付>订单生产>订单确认>订单完成。

而每个步骤的背后,订单是如何在多系统之间交互流转的,可概括如下图:

订单创建:

用户下单后,系统需要生成订单,此时需要先获取下单中涉及的商品信息,然后获取该商品所涉及到的优惠信息,如果商品不参与优惠信息,则无此环节。

接着获取该账户的会员权益,这里要注意的是:优惠信息与会员权益的区别,比如:商品满减是优惠信息,SUPER会员全场9.8折指的是会员权益,一个是针对商品,另一个是针对账户。其次就是优惠活动的叠加规则和优先级规则等。

增减库存规则是指订单中的商品,何时从仓储系统中对相应商品库存进行扣除,目前主流有两种方式:

下单减库存——即用户下单成功时减少库存数量

  • 优势:用户体验友好,系统逻辑简洁;
  • 缺点:会导致恶意下单或下单后却不买,使得真正有需求的用户无法购买,影响真实销量;

解决办法:

  1. 设置订单有效时间,若订单创建成功N分钟不付款,则订单取消,库存回滚;
  2. 限购,用各种条件来限制买家的购买件数,比如一个账号、一个ip,只能买一件;
  3. 风控,从技术角度进行判断,屏蔽恶意账号,禁止恶意账号购买。

付款减库存——即用户支付完成并反馈给平台后再减少库存数量

  • 优势:减少无效订单带来的资源损耗;
  • 缺点:因第三方支付返回结果存在时差,同一时间多个用户同时付款成功,会导致下单数目超过库存,商家库存不足容易引发断货和投诉,成本增加。

解决办法:

  1. 付款前再次校验库存,如确认订单要付款时再验证一次,并友好提示用户库存不足;
  2. 增加提示信息:在商品详情页,订单步骤页面提示不及时付款,不能保证有库存等。

综上所述,两种方式各有优缺点,因此,需结合实际场景进行考虑,如:秒杀、抢购、促销活动等,可使用下单减库存的方式。而对于产品库存量大,并发流量没有那么强的产品使用付款减库存的方式。

将两种方式带入到销售场景中,关联商品类型、促销类型、供需关系等,灵活使用,以充分发挥计算机系统的优势。

订单支付:

用户支付完订单后,需要获取订单的支付信息,包括支付流水号、支付时间等。支付完订单接着就是等商家发货,但在发货过程中,根据平台业务模式的不同,可能会涉及到订单的拆分。

订单拆分一般分两种:

  • 一种是用户挑选的商品来自于不同渠道(自营与商家,商家与商家);
  • 另一种是在SKU层面上拆分订单:不同仓库,不同运输要求的SKU,包裹重量体积限制等因素需要将订单拆分。

订单拆分也是一个相对独立的模块,这里就不详细描述了。

订单生产:订单生产,是指产品从企业到用户这一流程的概述。如电商平台中,商家发货过程已有一个标准化的流程,订单内容会发送到仓库,仓库对商品进行打单、拣货、包装、交接快递进行配送。

订单确认:收到货后,订单系统需要在快递被签收后提醒用户对商品做评价。这里要注意,确认收到货不代表交易成功,相反是售后服务的开始。

订单完成:订单完成是指在收到货X天的状态,此时订单不在售后的支持时间范围内。到此,一个订单的正向流程就算走完了。

(2)逆向流程

上面说到逆向流程是各种修改订单、取消订单、退款、退货等操作,需要梳理清楚这些流程与正向流程的关系,才能理清订单系统完整的订单流程。

订单修改:可梳理订单内信息,根据信息关联程度及业务诉求,设定订单的可修改范围是什么,比如:客户下单后,想修改收货人地址及电话。此时只需对相应数据进行更新即可。

订单取消:用户提交订单后没有进行支付操作,此时用户原则上属于取消订单,因为还未付款,则比较简单,只需要将原本提交订单时扣减的库存补回,促销优惠中使用的优惠券,权益等视平台规则,进行相应补回。

退款:用户支付成功后,客户发出退款的诉求后,需商户进行退款审核,双方达成一致后,系统应以退款单的形式完成退款,关联原订单数据。因商品无变化,所以不许考虑与库存系统的交互,仅需考虑促销系统及支付系统交互即可。

退货:用户支付成功后,客户发出退货的诉求后,需商户进行退款审核,双方达成一致后,需对库存系统进行补回,支付系统、促销系统以退款单形式完成退款。最后,在退款/退货流程中,需结合平台业务场景,考虑优惠分摊的逻辑,在发生退款/退货时,优惠该如何退回的处理规则和流程。

(3)状态机

状态机是管理订单状态逻辑的工具。状态机可归纳为3个要素,即现态、动作、次态。

  1. 现态:是指当前所处的状态。
  2. 动作:动作执行完毕后,可以迁移到新的状态,也可以仍旧保持原状态。
  3. 次态:动作满足后要迁往的新状态,“次态”是相对于“现态”而言的,“次态”一旦被激活,就转变成新的“现态”了。

状态机的设计需要结合平台实际业务场景,将状态间的切换细化成了执行了某个动作。

以一个B2C商城的订单系统举例如下:

订单系统为了高效的对订单进行跟踪和管理,会对订单流程当中的关键节点,抽象出订单状态。而订单状态从不同用户的角度可分为,系统订单状态、商家订单状态、买家订单状态等。

对于订单系统来说,订单状态细分的颗粒度越细、越明确,订单系统管理的精度和可靠性就越高,比如:在待付款和待发货两个状态中,订单系统后台会细分为订单超时取消、订单支付失败、订单付款完成等。

因此,订单状态模块中,通常会维护状态映射表,以不同的用户角色对系统订单状态进行重新划分,以满足不同用户的需求。

除此以外,随着电商平台的不断发展,不同的业务类型,所对应的订单状态都会有所区别。所以,订单系统中一般会储存多套状态机,以满足不同的订单类型来使用。

订单系统的发展

订单系统的主体框架,和主要业务模块已基本讲完,那么随着企业的发展,业务量和业务形式不断变化,企业有可能形成多个订单系统并存以满足不同的业务需要的情况。

业务系统架构如下:

这种状况的出现,将会给平台带来非常大的发展瓶颈,如:

三个订单系统,每个订单系统处理不同类型的订单,没有统一的订单销量、订单状态信息,网站前台对订单的状态展示与控制不统一,只能是在网站前台会员中心硬代码维护一套面向会员的统一订单明细与状态数据。而无线侧上线后,由于不了解前台网站会员中心的订单状态管理逻辑,所以需要把前台网站的订单明细及状态管理再在无线应用侧再实现一遍。

三套后台订单系统与公共业务系统如会员中心、支付与财务、促销工具、客户分单等系统都需要对接一遍,公共业务处理逻辑不统一,一旦逻辑变更多个系统统一个接口都要修改一遍,接口的重复维护开发工作量大。

订单开发目前分到事业部,各个事业部只会考虑自己的逻辑,不会考虑公共架构,只会越走越远。碰到像无线这样的项目,需要对接各个事业部,无线侧应用上线进展慢。

因此未来的订单系统可拆分为订单中心与业务订单系统两个模块,以管理公司所有订单数据,并为各个模块提供统一服务。

业务系统架构如下:

最后

对于企业订单系统的搭建,并不是要做的大而全、也不是要小而精。而需要结合市场、公司、业务的实际情况来最终制定系统设计方案和产品迭代计划。

最终,和公司整体发展相互协调,相辅相成。

 

本文由 @sleeping 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 您好,问一下流程引擎和状态机。 订单系统里面是引入了一个流程引擎服务吗?还是使用状态机来实现得流程引擎?

    来自北京 回复
  2. 讲的有点浅啊,看到有点意思的地方正想深入了解下,直接就点到即止不讲了 😡

    来自四川 回复
  3. 你好,笔者。请问在正向流程图中的各个系统是理解为各个微服务,这样理解是没有问题的吧。谢谢

    来自四川 回复
  4. 大神,请问下:逆向流程里,不是应该订单支付成功后就要走退款申请了么?如何还能进行取消订单操作?

    来自北京 回复
    1. 退款是相对于钱,取消订单是相对于物或者发货。

      回复
  5. 大牛,请问可以详解一下那个上下游流程吗? 😳 新人表示有点看不太懂

    来自重庆 回复
  6. 新人学习,收获颇多

    来自四川 回复
  7. 赞,收益颇多,谢谢

    回复
  8. 途牛的订单的流程中 还有确认管理系统呢 哈哈哈……

    来自浙江 回复
    1. 【机智如你】

      来自江苏 回复
    2. 请问“确认管理系统”是啥?

      来自北京 回复
    3. 就是一个 确认收货接口吧,说的高大上一点 就是确认管理系统

      来自上海 回复
  9. 当公司业务规模比较大时肯定要分为各业务订单系统和订单中心,但是在订单上二者的联系是不是:业务系统提供订单包含基本信息:用户信息、商品信息、订单总金额、优惠金额、实付金额等——下单后订单中心生成订单,同时再次校验订单信息——订单中心和支付系统进行交互——订单支付完成。有几个问题:1、关于订单状态每个业务的都不一样,那就是订单中心做各业务订单状态的统一维护了?;2、每个业务订单系统和订单中心都需要和优惠系统及会员系统对接?;3、关于订单结算是业务系统系统自己负责还是订单中心统一维护?
    不知道我的理解是否正确,希望多多交流

    来自浙江 回复
    1. 我也有类似的问题,就是业务的订单系统和中台的订单系统,到底哪个在上层?

      来自北京 回复
  10. 大公司事业部多了 确实 容易出现多个订单系统的情况

    来自湖北 回复
  11. 很好的文章,道理都懂,但是我自己缺乏系统的整合。
    关于状态机和状态映射表的方法真的很赞。
    我也遇到过订单状态、订单关联方很多,跟开发讲解订单流程就要好久的情况,而且还经常无法理解透彻。想想如果当时有了状态机和状态映射表,真的是一目了然,省了很多沟通时间的成本,再次点赞。

    来自北京 回复
    1. 同学过奖,一同学习进步

      回复
  12. 退款应该也会退货吧,文中说不需要跟库存系统交互,我怎么感觉要交互呢?我理解错了?

    回复
    1. 退款会不会包含退货,这个看你的产品业务流程是怎么设计的了。如果在退款流程里面你也支持退货,可以是业务更加灵活,但是所带来的问题也是要考虑到的哈。

      回复
  13. 如果需要从各个公共服务系统调用:一是会花费大量时间,二是代码的维护成本非常高。因此,订单系统接入所需的公共服务模块接口,在订单系统即可完成对接公共系统的服务。

    笔者好,这一段话没看太明白,从各个公共服务系统调用信息不就是应该通过各个公共系统对外暴露接口做成服务来由订单系统调用来获取数据么?您的意思是这种方式比较慢?

    来自北京 回复
    1. 这里是说订单系统会集成一部分公共服务系统的接口,然后围绕订单逻辑组合好,供前台使用直接,这样前台就不必落接口逻辑。比如,一个散客会员订单和一个企业会员订单,会员系统是两个接口,如果前台要查关于订单的会员信息需要自己判断订单类型再到相应接口查,这样后来接口改了,所有前台都要改一遍。订单系统并非会落很多数据,大部分数据都是通过公共接口现查的。

      来自江苏 回复
    2. 明白您的意思了,谢谢

      来自北京 回复
    3. 这就是阿里大中台 小前台的概念吧

      来自上海 回复
  14. 由面引入,单点突破;让读者知其然更知其所以然,窥其原理,指其方向…..受教,受教;我也先去捣鼓捣鼓这个订单系统

    来自北京 回复
    1. 过奖过奖

      来自江苏 回复
  15. 最好能有真实的订单状态扭转图作为举例,更具备说服力

    来自浙江 回复
    1. 不同业务、不同的系统架构、不同的公司中,订单状态可能都会有差异,所以就只抽取了几个有代表性的状态进行了举例,这也是本文的作用吧,给初识订单系统的同学一些设计启发和方法。

      要画某个订单系统的状态流程图工作量实在太大,同学们还是要自力更生呀~

      来自江苏 回复
  16. 学习了,感谢分享

    回复
  17. 学习了,点赞~

    回复
  18. 我还是给个赞吧😂

    回复
  19. 觉得有点用处的话点赞就好了,不用打赏哈😂,不过还是谢谢打赏的朋友

    回复
    1. 画的图都好专业,学习了

      来自广东 回复