E-commerce 中訂單系統的設計

Max發表於2018-12-22

資料庫設計

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,並對庫存進行歸還等系列操作

下一篇將會介紹促銷系統的設計與實現,本篇的主要目的是介紹訂單系統的相關設計,為下一篇做一個鋪墊.

由於篇幅有限並沒有過多的細節,有疑問或者不妥的地方歡迎留言.

tree-ql 意在代替 dingo/api，幫助你開發高可用的 API

E-commerce 中促銷系統的設計
2018-12-26
高可用訂單系統設計
2019-01-19
電商系統設計之訂單
2018-07-30
支付系統訂單模型該如何設計？
2019-02-18
模型
Thinkphp訂單系統，DukuanCMS競價訂單系統，單品訂單管理系統，多產品訂單管理系統
2019-05-11
PHP
訂單系統：從0到1設計思路
2018-10-08
SAP CRM系統訂單模型的設計與實現
2019-01-22
模型
基於中臺思想的物流系統設計（二）：構建物流訂單能力
2018-10-27
Javaweb的例項--訂單管理系統--設計資料庫
2021-01-03
JavaWeb資料庫
設計一款通用訂單系統，支援四種交付模式
2019-02-26
模式
訂單服務的設計思考
2018-12-22
Java五種設計模式實現奶茶訂單生成系統小DEMO
2023-12-18
Java設計模式
SAP PP 中關於計劃訂單和生產訂單的日期計算
2011-05-16
Laravel 回撥系統的設計 Cybereits.com 白名單系統的設計
2018-02-01
Laravel
聊聊「訂單」業務的設計與實現
2023-03-17
遊戲中的技能系統設計
2019-10-17
遊戲
訂單系統中併發問題和鎖機制的探討
2014-05-06
一種經典的客戶關係管理系統(CRM)訂單模型的設計與實現
2022-05-15
模型
查詢當天的系統訂單記錄
2020-12-05
訂單管理系統分析及改進
2024-03-07
史上最簡單的推薦系統設計
2019-05-11
設計一個簡單的devops系統
2022-03-31
dev
電商系統設計之商品 (中)
2018-07-28
什麼樣的訂單系統軟體比較好用？
2020-05-22
百萬訂單規模系統的技術治理實踐
2024-01-17
訂單工作流中找不到“訂單流-通用”
2007-03-16
一次訂單系統重構實踐
2020-11-21
GameChange Solar喜獲Genius Tracker(TM)系統訂單
2022-07-12
GAM
smdms超市訂單管理系統之登入功能
2022-04-04
自己開發的一個SAP CRM訂單統計工具
2020-08-27
新零售SaaS架構：訂單履約系統架構設計（萬字圖文總結）
2024-03-06
架構
Schedule 排程系統設計（單機版）
2018-10-19
秒殺系統設計中的業務性思考
2019-03-03
ERP系統中的稽核模組設計(轉)
2007-08-01
javascript中的設計模式之釋出-訂閱模式
2020-07-22
JavaScript設計模式
有哪些適合批發企業使用的訂單系統
2021-12-21
微信支付訂單、退款訂單、轉款訂單的查詢
2016-08-16
展廳中控系統方案設計
2022-08-10