E-commerce 中订单系统的设计

E-commerce 中订单系统的设计

数据库设计
Order
订单系统的核心表自然是 orders 系列表，laravel 的迁移文件如下

 Schema::create('orders', function (Blueprint $table) {
    $table->increments('id');
    $table->string('number')->nullable()->comment('订单号');
    $table->unsignedInteger('address_id')->nullable()->comment('订单地址');
    $table->unsignedInteger('user_id')->index()->comment('用户id');
    $table->integer('items_total')->default(0)->comment('order每一个item的total的和 unit/分');
    $table->integer('adjustments_total')->default(0)->comment('调整金额 unit/分');
    $table->integer('total')->default(0)->comment('需支付金额 unit/分');

    $table->string('local_code')->comment('语言编号');
    $table->string('currency_code')->comment('货币编号');

    $table->string('state')->comment('主状态 checkout/new/cancelled/fulfilled');
	    $table->string('payment_state')->comment('支付状态checkout/awaiting_payment/partially_paid/cancelled/paid/partially_refunded/refunded');
    $table->string('shipment_state')->comment('运输状态 checkout/ready/cancelled/partially_shipped/shipped');

    $table->ipAddress('user_ip')->comment('用户ip ip2long后的结果');

    $table->timestamp('paid_at')->nullable()->comment('支付时间');
    $table->timestamp('confirmed_at')->nullable()->comment('确认订单时间');
    $table->timestamp('reviewed_at')->nullable()->comment('评论时间');
    $table->timestamp('fulfilled_at')->nullable()->comment('订单完成时间');

    $table->json('rest')->nullable()->comment('非核心字段冗余');

    $table->timestamps();
 });

接下来是 order_items 表，用于记录 order 的 item

Schema::create('order_items', function (Blueprint $table) {
    $table->increments('id');
    $table->unsignedInteger('order_id')->index()->comment('外键');
    $table->unsignedInteger('variant_id')->comment('variant是国外的称呼,国内通常称为sku. 既库存最小单位');
    $table->unsignedInteger('product_id')->comment('冗余字段');
    $table->unsignedInteger('quantity')->comment('购买数量');

   // adjustment calculate
    $table->integer('units_total')->default(0)->comment('item中每一个unit的和. 单位/分');
    $table->integer('adjustments_total')->default(0);
    $table->integer('total')->default(0)->comment('units_total + adjustments_total');
    $table->integer('unit_price')->default(0)->comment('variant单价,冗余字段');

    $table->json('rest')->nullable()->comment('非核心字段冗余');
    $table->timestamps();
});

做过海外电商或者亚马逊的朋友应该对 variant (变体) 不陌生。国内称为 sku. 每一个商品都会有多个变体

接下来是 order_item_units 表

 Schema::create('order_item_units', function (Blueprint $table) {
    $table->increments('id');
    $table->unsignedInteger('item_id')->index();
    $table->unsignedInteger('shipment_id')->comment();
    $table->integer('adjustments_total')->default(0);
    $table->timestamps();
});

对于用户购买的每一件实体，我们都需要谨慎的做一条记录，其会涉及到运输 / 促销 / 退货等问题，例如 variantA 我们购买了三件，那么我们就需要为这三件相同的变体分别创建三条记录.

上面三张表的关系从上往下 一个 order 会有多个 item, 一个 item 根据 quantity 的值，会有对应数量的 unit.

order 和 order_item 表大家应该都知道.

order_item_units 表可能有些同学第一次知道，但是其是必要存在的

tip: 所有的价格字段都使用分为单位存储，从而避免小数在计算机系统中存在的一些问题

可以消化梳理一下上面的三张订单系统核心表，然后再介绍一下其他相关表的设计。数据库的设计应该是灵活的，可以根据实际的需求任意添加和修改字段

Adjustment
上面三张表都出现了 adjustment_total 字段，可能会有些疑惑.

如果我们每个变体的价格是 10 元，那我买三个这件变体则需要 30 元，但是实际支付的金额往往都不是 30 元., 会有各种各样的情况影响我们最终支付的价格.

比如运费 + 5 元，促销折扣 -8 元，税收 + 3 元，退还服务 +0.5 元，最后实际需要支付 35.5 元。为什么 30 元的金额最后却支付了 35.5 元？

我们不能凭空蹦出个 35.5 元，影响商品实际支付金额的每一个因素都是至关重要，我们需要负责任的记录下来。这便是 adjustment 表的来源.

首先看看迁移文件

 Schema::create('adjustments', function (Blueprint $table) {
	    $table->increments('id');
	    $table->unsignedInteger('order_id')->nullable();
	    $table->unsignedInteger('order_item_id')->nullable();
	    $table->unsignedInteger('order_item_unit_id')->nullable();
	
	    $table->string('type')->comment('调整的类型 shipping/promotion/tax等等');
	
	    $table->string('label')->comment('结合type决定');
	
	    $table->string('origin_code')->comment('结合label决定');
	
	    $table->bool('included')->comment('是否会影响最终订单需要支付的价格')
	        $table->integer('amount');
	    $table->timestamps();
	
	    $table->index('order_id');
	    $table->index('order_item_id');
	    $table->index('order_item_unit_id');
	});

调整对订单价格的影响分为三种类型，分别是 影响整个 order, 影响 order_item (较少预见), 影响 order_item_units.

included 字段 用来判断本条 adjustment 记录，是否会影响消费者最终需要支付的金额

大部分的 adjustment 都会影响最终结算的价格，小部分如商品税，通常已经计算在了商品的单价中，不会影响消费者最终需要支付的金额。但是在开具发票时 却需要展示，因为我们做必要的记录

举个例子，假设我们一笔订单的运费是 5 元，那么会有这样一条 adjustment 记录

 {
	    id: 1,
	    order_id: 1,
	    order_item_id: null,
	    order_item_unit_id: null,
	    amount: 500,
	    type: 'shipping',
	    label: 'UPS',
	    origin_code: null,
	    included: 1,
	}

假设我们消费者在一个订单中购买了三条 1.5 米数据线，并使用了一张 8 元的代金券，那么会有这样三条 adjustment 记录

[
    {
        id: 2,
        order_id: null,
        order_item_id: null,
        order_item_unit_id: 1,
        amount: -267,
        type: 'promotion',
        label: '8元代金券',
        origin_code: 'KSDI12K2', // 代金券code
        included: 1
    },
    {
        id: 2,
        order_id: null,
        order_item_id: null,
        order_item_unit_id: 2,
        amount: -267,
        type: 'promotion',
        label: '8元代金券',
        origin_code: 'KSDI12K2', // 代金券code
        included: 1
    },
    {
        id: 2,
        order_id: null,
        order_item_id: null,
        order_item_unit_id: 3,
        amount: -266,
        type: 'promotion',
        label: '8元代金券',
        origin_code: 'KSDI12K2', // 代金券code
        included: 1
    },

]
实际上对于大部分的促销需求 我们都应该将促销的折扣金额均分到每一个 unit 中.

这样设计的一个好处是，当消费者退调用其中一根数据线时，我们可以很清楚的计算出应该退多少金额给消费者。既 单价 + order_item_unit.adjustment

实际上清楚的记录每一笔影响最终支付金额的 adjustment, 无论对消费者还是对供应商来说都是负责的做法.

运费为什么不需要分摊到 unit?

运费对于一笔订单来说，是固定的外部消费 (由快递公司获利), 退款时商家并不需要为运费负责，只需要退还商品的等额价值即可

更加白话的说法就是 你在淘宝买了一个商品 20 元，运费 10 元，你觉得商品不好想要退货 (不考虑寄回的运费), 商家需要退你 30 元吗？

Shipment/Payment
shipment 为订单的运输信息存储，payment 为支付信息存储。先来看看迁移文件

 Schema::create('shipments', function (Blueprint $table) {
	    $table->increments('id');
	    $table->unsignedInteger('method_id')->comment('运输方式 外键');
	    $table->unsignedInteger('order_id')->comment('订单 外键');
	    $table->string('state')->comment('运输状态');
	    $table->string('tracking_number')->nullable()->comment('订单号码');
	    $table->timestamps();
	
	    $table->index('order_id');
	});
Schema::create('payments', function (Blueprint $table) {
	    $table->increments('id');
	    $table->unsignedInteger('method_id')->comment('支付方式');
	    $table->unsignedInteger('order_id');7
	    $table->string('currency_code', 3)->comment('冗余 货币编码');
	    $table->unsignedInteger('amount')->default(0)->comment('支付金额');
	    $table->string('state');
	    $table->text('details')->nullable();
	    $table->timestamps();
	
	    $table->index('order_id');
	});

上面在 order_item_units 表中存在一个 shipment_id 就对应这里的 shipment 表. shipment 和 order_item_units 之间是一对多的关系，订单中的每一个实体都可以被分别运输，例如京东购物时经常会见到这种情况.

一条 shipment/payment 会和一条实际存在的货运记录 / 支付记录 (退款记录) 挂钩.

上面就是订单系统的核心表了，对于后端来说，数据库就已经可以反映出整个系统的设计了.

接下来抽出一些细节进行详细的介绍

业务设计
状态的设计
相信很多小伙伴在做订单系统时会被各种状态 待确认，待支付，待发货，已发货，关闭订单 等等弄的晕头转向，今天我们就来梳理一下订单系统中的各种状态

如果各种状态只在 order 表使用一个 state 字段来记录显得有些力不从心，因此推荐使用三个字段，它们分别是 state,shipment_state,payment_state. 来分别记录在订单中我们或者消费者最关心的三种状态.

先来分别看看三个 state 的状态转移图

order.state↓

这是一笔订单的几个最基本的几个状态.

先讲一讲初始状态，既 checkout, 这与订单在什么时候创建有关系，当消费者在购物车点击结账时，就创建了一个订单，用于本次结账，因此订单的初始状态为 checkout

结账也就是所谓的确认订单页，在该页面中，消费者可以选择优惠券，选择地址等操作

处于该状态的订单对于后台管理系统 / 用户个人中心都是不可见的，且 checkout 类型订单的创建，也不会是库存有任何的变化

当用户在结账界面操作完成后需要用户点击确认订单。既行为 confirm 的触发，使订单的状态从 checkout 转换成了 new. 此时的订单无论是对于消费者 / 运营人员 / 仓储系统来说，都是真实存在且有效的。且响应的购物车记录也被清空。对于一笔状态为 new 的订单，消费者可以对其行使付款的权利.

order.payment_state↓

payment 的初始状态为 checkout 与上述一致.

当消费者触发 confirm 后，我们就可以触发 request_payment 行为，将订单的付款状态转换为 await_payment, 且将消费者引导到支付界面，当消费者支付成功后，在支付成功的回调中，触发 pay 行为，将支付状态转换为 paid.

关于退款的状态如上图所示，需要注意的是，对于退款，会出现只需要退订单中的部分商品的情况，因此加入了 partially_refunded (部分退款的状态).

order.shipment_state↓

当消费者 confirm 后，我们同时也需要调用响应的 request_shipment, 将我们的运输状态设置为一个 ready 状态，此时库存已经锁定.

关于仓库具体的备货时机 是在用户确认订单之后，还是等用户支付完成之后，需要根据实际的产品需求确定.

上面的状态图属于前者，当消费者确认订单后，便锁定了库存，并开始了备货阶段。如果是后一种情况可以将 checkout 修改为 pending, 等待消费者付款完成后再将状态转移到 ready

对于上面繁杂的状态转换，可以手动处理，也可以选择使用 state-machine 进行处理

订单价格的计算
单价作为一件商品的固有属性，不会受到运输 / 促销折扣等等因素的影响。当商家对一个价值 100 元商品进行一个 30% 的折扣时，消费者只需要用 70 元的价格买入，但实际上商品的单价依旧是 100 元.

当一笔订单不存在任何的 adjustment 时，我们可以很容易的计算出订单的实际支付价格，只需要把各个 order_item 的 unit_price * quantity 相加起来即可

但是有了 adjustment 参与之后，我们必须自下往上的计算。下面的例子是在 laravel 项目且使用了上述的数据库设计后的一个计算方法.

  public function calculator(Order $order)
{
    $items = $order->items;
    $items->load('adjustments', 'units.adjustments');
    $order->load('adjustments');

    $items->each(function ($item) {
        $item->units->each(function ($unit) {
            $unit->adjustments_total = $unit->adjustments->sum('amount');
        });

        $item->units()->saveMany($item->units);

        $item->adjustments_total = $item->adjustments->sum('amount');

        $item->units_total = $item->quantity * $item->unit_price + $item->units->sum('adjustments_total');

        $item->total = $item->units_total + $item->adjustments_total;
    });

    $order->items()->saveMany($items);

    $order->adjustments_total = $order->adjustments->sum('amount');
    $order->items_total = $order->items->sum('total');
    $order->total = $order->items_total + $order->adjustments_total;
    $order->save();
}

补充
当订单创建的同时 (结账阶段) 就分别创建了一条 payment / 和 shipment 记录。在 payment 和 shipment 中分别记录了用户选择的支付方式与运输方式.

在电商系统中，通常会有多种多样的支付方式和运输方式.

但是在实际的业务编写时，业务层并不希望关心和处理繁杂的支付与运输方式，此时支付网关和运输网关便应运而生，其对业务层隐藏了繁杂的细节，而暴露出了统一的 api 接口.

支付网关如提供商业服务的 ping++, 当然也有一些开源项目对这方面有所支持。如 yansongda/pay , Payum/Payum 等等

对于确认了但超过一定时间没有付款的订单，我们可以选择主动关闭该订单。将 order.state/order.payment_state/order.shipment_state 设置为 cancelled, 并对库存进行归还等系列操作