超詳解析訂單系統架構「電商訂單系統產品架構」

訂單系統作為一個業務子系統，在電商、零售、餐飲、教育、醫療saas系統中都非常常見。

只要平台存在交易行為，那麼必然逃不開訂單系統，因為最終都需要通過創建訂單，並支付，從而完成交易。

由於訂單系統的高出現頻率，且不同業務的訂單設計思路大同小異，所以我們可以把它作為一個底層系統進行抽象，建立一套訂單的設計模型，便於我們快速應用到各個業務系統之中。

訂單系統架構

No. 1

以電商為例：

訂單作為電商最複雜的核心系統（或者稱之模塊），它建立其他系統模塊之上。

包括但不限於商品、優惠券、會員、營銷活動、地址信息、積分、運費、購物車、支付、發收貨等模塊，都和訂單息息相關，任何一個模塊的改動，都可能影響到訂單。不誇張的說，訂單是交易平台最核心的子系統。

訂單包含的信息：

電商訂單系統架構：

因此做好訂單管理，最重要的是覆蓋的全面性、和極強的可擴展性。

訂單系統模塊拆分

No. 2

訂單主要分：訂單創建和訂單管理兩部分.

一、訂單創建：

訂單創建可以由C端用戶、以及B端使用者發起創建，並在訂單系統中生成。

訂單創建的節點，在頁面上的展示，就是提交訂單頁面點擊「提交訂單」按鈕那一刻，訂單就會被創建。

當然表面上看，點擊「提交訂單」就觸發了訂單創建，但背後，創建過程會調用前面所說的各個模塊，並且夾雜了大量的邏輯判斷。

提交訂單頁原型：

以下為訂單生成的校驗：

即在「提交訂單」那一刻，會進行多個信息的邏輯判斷

配送信息：配送方式和配送地址。

需判斷是否填寫了配送方式和地址；（如果是外賣）配送地址是否超過配送範圍；

商品

1. 需判斷商品是否是上架狀態；
2. 商品是否售罄；
3. 商品庫存是否小於訂單中的商品數量；（如有贈品贈送）需判斷贈品是否庫存不足；

運費

1. 選擇收穫地址後，會根據後台的運費模版自動進行運費計算，並回顯在【提交訂單】頁；
2. 提交訂單時需要校驗運費信息是否變動；

促銷活動

需判斷當前該用戶、該訂單商品適用的所有促銷活動。促銷活動一般分平台級、店鋪級2個層級

1. 平台級：針對平台內商品的促銷活動；
2. 店鋪級：針對店鋪內商品的促銷活動。

當然一般這類活動還有一些限制條件，比如

1. 訂單滿多少金額才可以參與
2. 只限一定等級的會員
3. 只限某些類目，或指定商品才可以參與
4. 如果同時滿足多個活動參與的條件，則只能參與優先順序最高的活動；

等等，視促銷活動數量和複雜度而定。

會員優惠

提交訂單時需判斷會員等級及相應優惠權益是否變動，需判斷可用積分數量是否變動。

優惠券

1. 需要判斷優惠券是否已核銷；
2. 是否已過期；
3. 是否在適用時段內；
4. 是否已被使用等。

一旦提交訂單後，則訂單即完成創建，這個時候訂單模塊還會發起指令要求其他模塊進行相應的配合：

1. 訂單中的商品庫存需要在商品模塊中進行凍結處理
2. 訂單中使用的優惠券需要在優惠券模塊中進行狀態變更
3. 訂單中使用的促銷活動權利應該標記為已使用該權利
4. 訂單中扣減的積分應該在用戶積分中進行扣減等

當然對於外賣而言，還需要在提交訂單的時候對店鋪是否在休息時間、店鋪是否開啟該配送方式、訂單價格是否滿足起送價等各種情況進行確定，如存在變動則給出用戶相應提示。

二、訂單管理

當訂單被創建後，即進入訂單管理階段。

C端頁面：

B端的訂單管理頁：

訂單輪轉流程：

關於訂單狀態

從用戶端（買家）角度看，電商平台的訂單流轉中間狀態一般有如下6大狀態：

1）待付款：當用戶提交訂單後，支付之前，都屬於待付款狀態，商家端也是待付款狀態。

2）待發貨：當用戶完成支付後，訂單狀態變更為待發貨，商家端也同步更新為「待發貨」狀態。

3）待收貨：當商家在後台確認發貨後，訂單狀態在買家端的顯示就會變成「待收貨」狀態，在賣家端會顯示「已發貨」，這裡兩邊的展示會有一個區別。

假如買家收到貨一直不點確認，那麼一般平台會有一個周期（淘寶是14天），14天後系統自動確認收貨，變更為交易成功。

4）退款中：一共兩種情況會導致訂單變更為「退款中」的狀態。

1. 是在「待收貨」狀態下，即商家已經發貨後，買家進行退款操作，那麼訂單狀態會直接變成退款中；
2. 是在「待發貨「狀態下，買家取消訂單／賣家操作全額退款，則進入退款中狀態。
3. 是買家確認收貨後，申請退款，則進入」退款中「狀態，一般電商平台都支持確認收貨後7天無理由退貨

5）交易完成：一共有兩種情況會導致訂單變更為」交易成功「

1. 是用戶確認收貨；
2. 是買家申請部分退款，退款流程結束，且剩餘商品確認收貨後，訂單變更為「交易成功」。

6）交易關閉：一共有3種情況會出現「交易關閉」

1. 是「交易成功」後發起全額退款，完成退款流程變更為「交易關閉」；
2. 是在」待支付「的時候買家取消訂單／訂單超時過期）；
3. 是「待發貨」的時候買家申請退款，商家確認後訂單變更為「交易關閉」。

關於訂單中的優惠分攤

為什麼要考慮優惠分攤，如果下單的時候使用了某種優惠活動，當訂單進行部分退款的時候，我們肯定不能給買家直接退商品的原價，這樣對賣家的損失就很大了。

因此在訂單生成時，就會針對使用優惠活動的商品計算優惠分攤。

舉例

我們舉個最簡單的例子，買家購買了一個商品A100元，一個商品B200元，提交訂單時參與了滿100減50的促銷活動，那麼最後支付了250元。

假如買家收到貨後覺得A不滿意，申請退款，賣家同意後且完成退款流程後，應該退給A多少呢？

A的退款金額=100*250/（100+200）=83.33元（保留2位小數點）

他並不能收到100元，因為假如他收到了100元，相當於最終用了150元買到了B，這是存在漏洞的。

再舉個更複雜的案例：這個案例涉及到平台跨店促銷優惠、店鋪促銷優惠、優惠券優惠券

舉例

買家購買了1個商品A100元（甲店）、1個商品B200元（甲店）、1個商品C300元（乙店）。

提交訂單時，參與甲店的滿200減50的促銷活動1，同時還參與了平台滿200減100的促銷活動2，此外還使用了一張150元的平台代金券。

那麼根據優先順序首先A+B的商品享受甲店的活動1後變成了（100+200-50）=250元，然後A+B+C繼續參與平台的活動2後變成了（250+300-100）=450元，最終使用一張平台代金券後支付（450-150）=300元，即最終需支付300元。

即依次按照活動1>活動2>代金券的優先順序進行參與。

假設退款時，是無法退還代金券的，那麼在訂單生成時，我們來計算下每一層優惠分攤之後，A、B、C的可退金額是多少：

第一層：活動1分攤後

商品A=100-50/（100+200）*100=83.33元

商品B=200-50/（100+200）*200=166.67元

商品C=300元

第二層：活動2分攤後

商品A=83.33-100/550*83.33=68.18元

商品B=166.67-100/550*166.67=136.37元

商品C=300-100/550*300=245.46元

注釋：83.33+166.67+300=550元

第三層：代金券分攤後

商品A=68.18-150／450*68.18=45.45元

商品B=136.37-150/450*136.37=90.91元

商品C=245.46-150/450*245.46=163.64元

注釋：68.18+136.37+245.46=450元

所以經過優先順序從高到底的三層優惠分攤後，A最終的實際可退金額為45.45元，B為90.91元，C為163.64元

2、關於拆單

在電商平台中，只要有購物車功能，就會出現買家跨店購買商品的情況。

比如一筆訂單買了甲店的商品A一件，買了乙店的商品B一件，對於買家來說，他只是下了一筆訂單；但是對平台來說，需要把A的訂單信息推送給甲店，把B的訂單信息推送給乙店，這就需要對買家的訂單進行拆單。

另外對於提交給甲店的訂單來說，如果訂單包含多個商品A、B、C，可能還會涉及到發貨單的拆單，比如A、B一起發貨，C單獨發貨。