基础平台设计-订单系统（一）

前言

在互联网公司里，都会涉及到中台管理端，或被称OSS，或称Console。它主要承担的职责是对底层的基础模块、数据等进行可视化，便于管理端的业务操作人员更加简单、高效、便捷的处理事务。本文重点介绍【订单系统】的框架结构、流程、状态机扭转、字段设计，作为【订单系统】系列文章的开篇。

一、订单系统框架结构      

订单系统处于承上启下的关键位置

1.1、对于用户端，如APP、小程序、PC等，用户对订单的增删改查（查询订单、确认订单、取消订单、支付订单等等），均需要向订单系统发出请求并由其来完成对应的操作。

1.2、对于底层公共服务，如用户系统（用户的基础信息，如姓名、昵称、手机号等）、交易系统（微信支付、支付宝支付）、消息系统（向用户触达消息，APP PUSH、短信、弹窗等）。则听令于订单系统的调遣，协助订单系统完成闭环流程。

1.3、另外。不同类型的订单涉及的相关模块也不尽一致。如电商类订单，则必然涉及商品模块；为了营销目的而产生的各类优惠券，也会属于订单的一个属性。当然，订单必不可少是是发起订单的主体，也就是用户，所以与用户模块息息相关。

二、订单流程及状态机扭转

订单系统可简可繁，随着业务的处在不同的阶段，订单系统也会随之发生改变。从流程上看，一般可以认为基础的流程有4大块：订单创建、订单支付、订单确认、订单完成/关闭。

以下通过几类常见互联网商品的订单，展示订单的流程及状态机扭转：

2.1、虚拟商品（如会员卡、在线课程、名师咨询等）

2.2、实物商品（涉及物流，商家发货、买家确认等）

三、订单字段设计

一笔订单涉及到的字段，基本上可以由下述脑图概述完整。一般我们考虑：用户信息、商品信息、支付信息、状态信息、促销信息、配送信息、时间信息等。

我们在设计时，可引入中台的概念，做好字段拓展，如【订单渠道】。这样，即使后续业务越来越多，从一开始设计的订单系统，通过订单渠道进行区分，也可大大的对不同业务进行兼容和拓展。