一、订单实体

图片.png

l 订单基本信息

一般设计在订单主体的实体表中，用于订单模型内聚的核心。

包括订单号和若干的统计数据。

l 订单项目

表示该订单对应那些选购的产品。数据从购物车获取，但需要注意的是，顾客可以选择购物车的全部或部分产品进入结账流程，需要持久化到订单项目的是进入结账流程的购物车项目。

l 订单促销和促销项目关联

由于可以选择全部或部分的购物车项目进行结账，所以购物车聚合实体中所存储的促销和促销关联将不能直接复制到订单中，可以同样的调用促销模块的接口获得数据，而且这样做会带来额外的好处，就是订单和购物车耦合进一步降低。

基于购物车 + 结账，只是生成订单的一种方式，所以订单模块所提供的生成订单接口应该和这些模块越松耦合越好。

l 订单支付

支持多种支付方式。

注：对于信用卡方式，在国外习惯支持信用卡支付，所以网站会保存信用卡类型、卡号和安全码，但这样如果一旦泄露，将会对网站带来很大麻烦。所以一就是加密保存 或 通过支付网关来满足信用卡支付的情况。

l 订单运输地址

结账时从顾客地址中选择一个地址记录，并将此地址记录冗余订单地址表中。这样的设计考虑是避免顾客下达订单后，修改该地址而影响已生成的订单。

l 订单发票信息

一般而言一张订单只需要配置一条发票信息，但不排除会有不同的开票需求。所以会设计为和订单一对多的关系。

l 订单备注

用于订单的相关方在订单上留言，沟通交流，解决纠纷使用。

l 订单台账

即订单日志，记录从订单整个生命周期所有的操作流水（涉及数据修改的操作），各类操作需要区分类型。

二、订单状态

图片.png

不同业务系统中订单的状态流程会有区别，本文是针对B2C电子商务系统，所以只考虑顾客和平台的交互，对于多商家系统，则需要

考虑顾客、商家和平台的交互了。

我设计的是B2C电子商务系统通用的订单状态，并将其分为两大类：

l 进入履行前

表示顾客下单后，订单管理员未审核通过之前。需要确认支付、订单信息等。

n 等待支付 Awaiting Pay

针对先付款的情况。

n 等待确认支付 Payment Verify

对于通过支付网关在线支付，一般由网关返回信息自动处理本状态。

n 等待确认信息 Info Verify

支付成功后 或 选择货到付款 后 ，需要订单管理员进行订单信息的确认，如地址是否有效，是否有库存等。

n 订单取消 Cancelled

前面三个状态均可以跳到订单取消。这是订单进入履行前的终止状态。如果已经支付了，则需要做退款处理。

l 进入履行后

表示顾客下单后，订单管理员审核通过之后。进入履行阶段后，订单不能取消。

n 等待备货 Awaiting Pick-up

再次检查库存并通过后，进入订单履行环节的第一个状态。

n 发货中 Shipping

生成第一张发货单，并设置该发货单状态为“发货中”时，订单的状态也更新发货中状态。

n 发货完毕 Shipped

设置发货单为“顾客已签收”时，判断该订单是否存在未发货的产品，如果没有，则订单的状态也更新为发货完毕状态。

n 发货中止 Ship Suspend

表示剩余未发货的产品因为库存原因无法履行（比如临时损坏了，又无法调货）。

n 订单完成 Completed

n 履行不能 Impossiblility

    表示进入履行阶段后，发现订单全部产品均缺货（临时损坏、无法调货等）。

注：如需查看详细的订单状态流图设计可以购买《Craft6.cn 电商研发方案-销售订单模型分析和设计》企业版。

三、支付状态

支付状态会影响订单状态流程，但业务上却相对独立，比如对于货到付款情况，订单的下达和履行不考虑支付状态。

所以将支付状态独立更容易设计，而且避免订单状态过多和过于复杂。

图片.png
图片.png

l 未支付 unpaid

l 部分支付 partial paid

下达订单时，如果已经选择积分或礼品卡支付了部分金额，则状态设置为此状态。

l 已支付 paid off

支付状态比较简单，读者看上面的支付状态流图即可。要注意的是支付状态会触发订单状态的变更。

即当是先付款时，订单完成支付后，将更新订单状态为等待支付确认状态，可以人工再确认，也可以自动跳过该状态。