电商仓储系统设计(电商系统)

昨天一个朋友去面试，被问到如何设计订单系统，主要是因为简历上有一个电子商务相关的项目，然后因为回答太片面而失败。所以，如果你的简历中也包含了商城项目，一定要仔细阅读这篇文章。

很多同学都在疑惑，为什么现在的商场项目烂，为什么那么多人写？因为一个好的商城项目，确实能把你所学的东西融会贯通，而且难度不会太高，所以一直是很多刚毕业学生的首选。当然，如果你技术过硬，绝对可以选择更多让人眼前一亮的项目。

之前写过一篇关于商城项目的文章，推荐过。感兴趣的朋友可以去看看。

推荐一个基于春靴的前端分离的商场，真正的保姆级别。

好了，八卦到此为止。本文主要讲述了订单系统在传统电子商务企业中的作用，梳理了订单系统主要功能模块的设计思路，并对订单系统的未来发展做了一些思考。

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

在建立企业订单系统之前，需要梳理企业整个业务系统之间的关系，以及订单系统上下游之间的关系。只有划分业务系统的边界，才能确定订单系统的职责和功能，从而确保各个系统之间高效、简洁的工作。

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

关系图关系图

(1)外部系统:

企业外部用户使用的所有系统都在这一层，包括官网和普通用户使用的C端，以及商家使用的后台系统和各销售渠道的分销系统。比如和银行信用卡中心合作，微信合作，在合作伙伴的平台上揭示企业的产品。这种系统站在与客户接触的最前沿，是公司实现商业模式的桥头堡。

(2)管理中后台:

每个C端业务形态都会有相应的系统模块，比如管理平台交易的订单系统，管理优惠信息的推广系统，管理平台所有产品的产品系统，管理所有外部系统展示的内容系统。

(3)公共服务体系:

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

3. 订单系统上下游关系

上下游关系图上下游关系图

可以看出，订单系统接收用户信息，将用户信息转化为产品订单，对订单信息和数据进行管理和跟踪，承担着公司整个交易线重要的面向客户的环节。下面链接产品系统、推广系统、仓储系统、会员系统、支付系统等。，在整个电商平台中起着承上启下的作用。

5. 订单系统的业务架构

订单业务架构订单业务结构

(1)订单服务

该模块的主要功能是用户日常使用的服务和页面，包括订单列表、订单明细、在线订购等。还包括公共业务模块的多维订单数据服务。

(2)顺序逻辑

订单系统的核心起着至关重要的作用。订单系统负责订单创建、订单支付、订单生产、订单确认、订单完成和订单取消。还涉及到复杂的订单状态规则、订单金额计算规则、库存增减规则等。在第4节的核心功能设计中将会强调这一点。

(3)底层服务

信息化达到一定水平的企业，一般会将自己的公共服务，比如产品，模块化，建设相应的产品体系，有相对独立的代码、数据库和接口。但也带来了一个问题，比如订单创建场景中要获取的信息分散在各个系统中。

如果需要从各种公共服务系统调用，首先要耗费大量时间，其次代码的维护成本非常高。因此，当订单系统访问所需的公共服务模块接口时，可以在订单系统中完成对接公共系统的服务。

订单系统核心功能1. 订单中所包含的内容信息

核心内容核心内容

为了使订单系统能够高效、准确地管理和跟踪订单，订单将存储一系列关于产品、优惠、用户、支付信息等订单实时数据。，并与下游系统互动，如促销、仓储、物流等。

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

这里要注意的是订单类型。随着平台业务的不断发展，在丰富品类、丰富交易方式之后，需要对订单进行多维度的分类管理。同时，订单类型有利于订单系统的可扩展性。每个订单类型对应一组流程和一组状态，便于订单的分类管理和重用。

2. 流程引擎

流程是指从平台的角度抽象出订单从创建到完成的整个流通过程，从而形成一套标准的流程规则。不同的产品类型或交易类型在系统中有不同的流程，所以为了方便管理订单流程，会设置一个流程引擎模块。

每套订单流程包括正向流程和反向流程。前进过程可以比作平稳的在线购物体验中后台系统之间的信息流。逆向流程是订单修改、订单取消、退款、退货等各种动作引起的后台系统流程。同时，每个流程的触发条件可以分为系统触发和手动触发两种场景。

(1)前进过程

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

在每一步之后，订单如何在多个系统之间交互流动可以总结如下:

流程流动

订单创建:

用户下单后，系统需要生成订单。这时候就需要先获取订单涉及的商品信息，再获取商品涉及的优惠信息。如果商品没有参与优惠信息，就没有这个链接。

然后获得这个账号的会员权限。这里要注意优惠信息和会员权益的区别。比如满减商品是优惠信息，超级会员9.8折是指会员权益，一个是商品，一个是账户。其次，优惠活动的叠加规则和优先规则。

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

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

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

解决方案:

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

通过付款减少库存——即付款完成并反馈给平台后，库存数量会减少。

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

解决方案:

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

综上所述，两种方法各有利弊。所以需要结合实际场景来考虑，比如秒杀、抢购、促销等。你可以用下订单的方法来减少库存。对于库存大，并发流量少的产品，采用货款减去库存的方法。

两种方法带入销售场景，涉及商品类型、促销类型、供求关系等。，并灵活运用，充分发挥计算机系统的优势。

付款:

用户支付订单后，需要获取订单的支付信息，包括支付流水号、支付时间等。支付订单后，我们等待商家发货。但是在发货的过程中，根据平台的商业模式不同，订单可能会拆分。

一般来说，订单拆分有两种:

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

订单拆分也是一个相对独立的模块，这里不再赘述。

生产:按订单生产是指从企业到用户的过程概述。比如在电商平台，商家的发货流程有一个标准化的流程，订单内容会送到仓库，仓库会通过快递下单、提货、包装、发货。

订单确认:收到货物后，在快递签收后，订单系统需要提醒用户对货物进行评价。这里需要注意的是，确认收货并不代表交易成功，而是售后服务的开始。

订单完成:订单完成是指收到货物后X天的状态，此时订单不在售后支持时间范围内。至此，一个订单的正向流转完成。

(2)逆向过程

逆向流程逆流

如上所述，反向流程就是修改订单、取消订单、退款、退货等各种操作。需要理清这些流程与正向流程的关系，才能理出订单系统完整的订单流程。

订单修改:可以整理订单中的信息，根据信息关联程度和业务需求设置订单的修改范围。比如客户下单后，想修改收货人的地址和电话。这时候你只需要更新相应的数据就可以了。

取消订单:用户提交订单后不付款。这个时候用户原则上是在取消订单，因为还没有付款，比较简单。只需要补足最初提交订单时扣除的股票。促销优惠中使用的优惠券、权益，要按照平台的规则来补。

退款:用户支付成功后，客户要求退款，商家需要审核退款。双方达成协议后，系统要以退款单的形式完成退款，并关联原始订单数据。因为商品没有变化，所以不需要考虑和库存系统的交互，只需要考虑促销系统和支付系统的交互。

退货:用户支付成功后，客户提出退货要求后，商家需要审核退款。双方达成协议后，库存系统需要补货，支付系统和推广系统会以退款单的形式完成退款。最后，在退款/退货流程中，需要结合平台业务场景考虑折扣分配的逻辑，以及发生退款/退货时如何退回折扣的处理规则和流程。

(3)状态机

状态机是管理订单状态逻辑的工具。状态机可以概括为三个要素，即当前状态、动作和次级状态。

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

状态机的设计需要结合平台的实际业务场景，将状态之间的切换细化为一个动作的执行。

以某B2C商城的订单系统为例:

B2C商城B2C购物中心

为了有效地跟踪和管理订单，系统将从订单流程中的关键节点提取订单状态。订单状态可以分为系统订单状态、商家订单状态、买家订单状态等。从不同用户的角度来看。

对于订单系统来说，订单状态细分的粒度越细越清晰，订单系统管理的准确性和可靠性就越高。比如在待付款和待发货两种状态下，订单系统后台会细分为超时取消、订单付款失败和订单付款完成。

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

另外，随着电商平台的不断发展，不同的业务类型会有不同的订单状态。因此，订单系统中通常存储多组状态机，以满足不同的订单类型。

订单系统的发展

订单系统的主要框架和主要业务模块已经基本完成，因此随着企业的发展，业务量和业务形式也在不断变化，企业有可能形成多个订单系统并存的局面，以满足不同的业务需求。

业务架构如下:

业务架构业务架构

这种情况的出现会给平台带来很大的发展瓶颈，比如:

有三个订单系统，每个系统处理不同类型的订单。没有统一的订单销售和订单状态信息，网站前台对订单状态的显示和控制各不相同。只有一套统一的会员订单明细和状态数据可以在网站前台会员中心硬代码维护。无线端上线后，由于不知道前端网站会员中心的订单状态管理逻辑，需要再次在无线应用端实现前端网站的订单明细和状态管理。

会员中心、支付财务、推广工具、客户计费等系统三套后台订单系统和对公业务系统都需要重新连接，对公业务的处理逻辑不统一。一旦逻辑发生变化，多个系统的所有接口都要修改，接口的重复维护和开发工作量大。

现在的订单都是分配给事业部，每个事业部只会考虑自己的逻辑，而不是公共架构，只会越走越远。到了无线这样的项目，需要和各个事业部对接，无线应用上线进度比较慢。

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

业务架构如下:

业务系统架构业务系统架构

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

最后会与公司整体发展相协调，相得益彰。