本文主要阐述了订单系统在传统电子商务企业中应承担的作用，对订单系统中的主要功能模块进行了设计思路的梳理，并对订单系统的未来发展进行了思考。
1 .订单系统在企业中的作用在建立企业订单系统之前，必须理顺整个企业业务系统之间的关系和订单系统的上下级关系，分清业务系统的界限，才能确定订单系统的职责和功能，保证各系统之间的高效简洁工作
2 .订单系统与各业务系统的关系
（1）对外系统：
用于企业外部用户的所有系统都在这一层，包括官方网站、普通用户使用的C端，也包括用于商户的商家后台和在各销售渠道流通的系统。 例如，与银行信用卡中心合作，或与微信合作，在合作商平台上曝光我们的产品。 这样的系统站在客户接触的最前沿，是公司实现商业模式的桥头堡。
（2）管理中后台：
各c端的业务形态包括：管理平台交易的订单系统、管理优惠信息的促销系统、管理平台所有产品的产品系统、管理所有对外系统的显示内容的内容系统等对应的系统模块
（3）公共服务系统：
随着企业的发展，信息化建设达到一定程度后，企业需要将通用功能服务化、平台化，以保证APP应用体系结构的合理性，提高服务效率。 这类系统主要为其他APP应用系统提供基础服务能力支持。
3 .从订单系统的上下级关系可以看出，订单系统在接收用户信息、将用户信息转换为产品订单的同时，管理和跟踪订单信息和数据，是整个公司交易线的重要客户环节。 其次结合产品系统、促销系统、仓储系统、会员系统、支付系统等，对整个电商平台起到了启示作用。
4 .订单系统业务结构（1）订单服务
本模块的主要功能是用户日常使用的服务和页面，主要有订单列表、订单详细信息、在线订单等，包括为公共业务模块提供的多维订单数据服务。
（2）订单逻辑
订单系统的核心，起着非常重要的作用，在订单系统中管理订单制作、订单支付、订单生产、订单确认、订单完成、订单取消等订单流程。 也与复杂的订单状况规则、订单金额计算规则、增减库存规则等有关。 在第4节的核心功能设计中重点是。
（3）底层服务
信息化建设发展到一定程度的企业，一般将公司公共服务模块化。 例如，所述产品构建相应的产品系统，并且代码、数据库、接口等相对独立。 但是，也存在订单制作时应该取得的信息分散在各系统中等问题。
如果需要从每个公共服务系统调用，一个是需要很长时间，另一个是代码维护成本非常高。 因此，订单系统可以访问所需的公共服务模块的接口，通过订单系统完成对公共系统的服务。
订单系统的核心功能1 .订单中包含的内容信息为了让订单系统能够有效准确地管理和跟踪订单，订单存储产品、优惠、用户、支付信息等一系列订单实时数据，与下游系统，如促销、仓储、物流进行交互。
以一般的B2C商城订单为例，将其内容整理如下。
这里需要注意的是订单类型，随着平台业务的发展，在种类丰富、交易方式丰富后，需要对订单进行多维分类管理，同时订单类型有利于订单系统的可扩展性。 每种订单类型都支持一系列流程和状态，便于订单的分类管理和重用。
2 .流程引擎流程是从平台的角度，将订单从创建到完成的整个流程过程抽象出来，形成标准的流程规则。 由于系统中的流程因产品类型和交易类型而异，因此为了便于管理订单流程，构建了流程引擎模块。
每个订单流程都包括前向流程和反向流程。 正向过程是一个顺畅的网络购物体验，可以比喻为后台系统之间的信息流。 反向流是由各种操作(如修改订单、取消订单、退款和退货)触发的后台系统流，每个进程触发的条件分为两种情况：系统触发器和手动触发器
（1）正向流程
以常见的B2C商城订单系统为例，根据实际业务场景，其订单流程包括五个步骤：订单创建订单支付订单生产订单确认订单完成。
每个步骤的背后，订单是如何在多系统之间相互流动的，可以归纳为下图。
订单创建：
用户下单后，系统需要生成订单。 在这种情况下，需要首先获取与订单相关的商品信息，然后获取与该商品相关的优惠信息。 如果商品不涉及优惠信息，就没有这个柜台。
其次，获得该账户的会员权益。 这里需要注意的是优惠信息和会员权益的差异。 例如，商品大量减少是指优惠信息，SUPER会员以9.8折的价格指会员权益。 一个是针对商品的，另一个是针对账户的。 其次是活动的重叠规则和优先级规则等。
库存增减规则是指订购的商品何时从仓库系统中扣除该商品的库存，目前主流有两种方法。
下单减库存——即用户下单成功时减少库存数量
优势
trong>缺点：会导致恶意下单或下单后却不买，使得真正有需求的用户无法购买，影响真实销量；解决办法：
设置订单有效时间，若订单创建成功N分钟不付款，则订单取消，库存回滚；
限购，用各种条件来限制买家的购买件数，比如一个账号、一个ip，只能买一件；
风控，从技术角度进行判断，屏蔽恶意账号，禁止恶意账号购买。
付款减库存——即用户支付完成并反馈给平台后再减少库存数量
优势：减少无效订单带来的资源损耗；
缺点：因第三方支付返回结果存在时差，同一时间多个用户同时付款成功，会导致下单数目超过库存，商家库存不足容易引发断货和投诉，成本增加。
解决办法：
付款前再次校验库存，如确认订单要付款时再验证一次，并友好提示用户库存不足；
增加提示信息：在商品详情页，订单步骤页面提示不及时付款，不能保证有库存等。
综上所述，两种方式各有优缺点，因此，需结合实际场景进行考虑，如：秒杀、抢购、促销活动等，可使用下单减库存的方式。而对于产品库存量大，并发流量没有那么强的产品使用付款减库存的方式。
将两种方式带入到销售场景中，关联商品类型、促销类型、供需关系等，灵活使用，以充分发挥计算机系统的优势。
订单支付：
用户支付完订单后，需要获取订单的支付信息，包括支付流水号、支付时间等。支付完订单接着就是等商家发货，但在发货过程中，根据平台业务模式的不同，可能会涉及到订单的拆分。
订单拆分一般分两种：
一种是用户挑选的商品来自于不同渠道（自营与商家，商家与商家）；
另一种是在SKU层面上拆分订单：不同仓库，不同运输要求的SKU，包裹重量体积限制等因素需要将订单拆分。
订单拆分也是一个相对独立的模块，这里就不详细描述了。
订单生产：订单生产，是指产品从企业到用户这一流程的概述。如电商平台中，商家发货过程已有一个标准化的流程，订单内容会发送到仓库，仓库对商品进行打单、拣货、包装、交接快递进行配送。
订单确认：收到货后，订单系统需要在快递被签收后提醒用户对商品做评价。这里要注意，确认收到货不代表交易成功，相反是售后服务的开始。
订单完成：订单完成是指在收到货X天的状态，此时订单不在售后的支持时间范围内。到此，一个订单的正向流程就算走完了。
（2）逆向流程
上面说到逆向流程是各种修改订单、取消订单、退款、退货等操作，需要梳理清楚这些流程与正向流程的关系，才能理清订单系统完整的订单流程。
订单修改：可梳理订单内信息，根据信息关联程度及业务诉求，设定订单的可修改范围是什么，比如：客户下单后，想修改收货人地址及电话。此时只需对相应数据进行更新即可。
订单取消：用户提交订单后没有进行支付操作，此时用户原则上属于取消订单，因为还未付款，则比较简单，只需要将原本提交订单时扣减的库存补回，促销优惠中使用的优惠券，权益等视平台规则，进行相应补回。
退款：用户支付成功后，客户发出退款的诉求后，需商户进行退款审核，双方达成一致后，系统应以退款单的形式完成退款，关联原订单数据。因商品无变化，所以不需考虑与库存系统的交互，仅需考虑促销系统及支付系统交互即可。
退货：用户支付成功后，客户发出退货的诉求后，需商户进行退款审核，双方达成一致后，需对库存系统进行补回，支付系统、促销系统以退款单形式完成退款。最后，在退款/退货流程中，需结合平台业务场景，考虑优惠分摊的逻辑，在发生退款/退货时，优惠该如何退回的处理规则和流程。
（3）状态机
状态机是管理订单状态逻辑的工具。状态机可归纳为3个要素，即现态、动作、次态。
现态：是指当前所处的状态。
动作：动作执行完毕后，可以迁移到新的状态，也可以仍旧保持原状态。
次态：动作满足后要迁往的新状态，“次态”是相对于“现态”而言的，“次态”一旦被激活，就转变成新的“现态”了。
状态机的设计需要结合平台实际业务场景，将状态间的切换细化成了执行了某个动作。
以一个B2C商城的订单系统举例如下：
订单系统为了高效的对订单进行跟踪和管理，会对订单流程当中的关键节点，抽象出订单状态。而订单状态从不同用户的角度可分为，系统订单状态、商家订单状态、买家订单状态等。
对于订单系统来说，订单状态细分的颗粒度越细、越明确，订单系统管理的精度和可靠性就越高，比如：在待付款和待发货两个状态中，订单系统后台会细分为订单超时取消、订单支付失败、订单付款完成等。
因此，订单状态模块中，通常会维护状态映射表，以不同的用户角色对系统订单状态进行重新划分，以满足不同用户的需求。
除此以外，随着电商平台的不断发展，不同的业务类型，所对应的订单状态都会有所区别。所以，订单系统中一般会储存多套状态机，以满足不同的订单类型来使用。
订单系统的发展订单系统的主体框架，和主要业务模块已基本讲完，那么随着企业的发展，业务量和业务形式不断变化，企业有可能形成多个订单系统并存以满足不同的业务需要的情况。
业务系统架构如下：
这种状况的出现，将会给平台带来非常大的发展瓶颈，如：
三个订单系统，每个订单系统处理不同类型的订单，没有统一的订单销量、订单状态信息，网站前台对订单的状态展示与控制不统一，只能是在网站前台会员中心硬代码维护一套面向会员的统一订单明细与状态数据。而无线侧上线后，由于不了解前台网站会员中心的订单状态管理逻辑，所以需要把前台网站的订单明细及状态管理再在无线应用侧再实现一遍。
三套后台订单系统与公共业务系统如会员中心、支付与财务、促销工具、客户分单等系统都需要对接一遍，公共业务处理逻辑不统一，一旦逻辑变更，多个系的同一个接口都要修改一遍，接口的重复维护开发工作量大。
订单开发目前分到事业部，各个事业部只会考虑自己的逻辑，不会考虑公共架构，只会越走越远。碰到像无线这样的项目，需要对接各个事业部，无线侧应用上线进展慢。
因此未来的订单系统可拆分为订单中心与业务订单系统两个模块，以管理公司所有订单数据，并为各个模块提供统一服务。