主子訂單模型
在展開討論之前，先需要給出一個比較清晰的定義，主子訂單是什麼？
如何界定主訂單
主訂單承載使用者購買行為中【某邏輯聚合維度內所有相關 SKUS】的動作和流轉。
邏輯聚合取決於具體的業務場景，接下來會根據得物的業務模型，大致分析【邏輯聚合】到底是什麼邏輯抽象，從表現上來看，主訂單是一個或者一些子訂單的聚合。
如何界定子訂單
子訂單承載使用者購買行為中 SKU 的動作和流轉。
所有電商都支援 SKU 維度的取消,退貨行為，這也是消費者的合法權利，為此需要一種模型去承接使用者購買行為中 SKU 的動作和流轉。
依據訂單現有的訂單資料結構和模型，在不做大改動的情況下，使用子訂單去承載使用者購買行為中 SKU 的動作和流轉。
所以我們需要明確回答-子訂單到底是什麼？
以某個專案為例：在球鞋定製時，從表面上看，在一次建立訂單的過程中，其費用項主要有三類：
- 實體商品
- 定製化服務
- 運費服務
在不考慮現有模型的基礎上，發散性的思考，可能有以下三種方案：
- 方案 1：是不是可以建立三個子訂單來完成上述邏輯的表達
- 方案 2：建立一個子訂單來完成上述邏輯的表達
- 方案 3：建立兩個子訂單來完成上述邏輯的表達
直覺告訴我們，應該採用方案 3：建立兩個子訂單來完成上述邏輯的表達；但是為什麼？任何方案都會有一個邏輯表達，兩個訂單的方案更優的邏輯表述是什麼？
觀察以上三個元素-實體商品，定製化服務，運費服務：
- 共同點是：它們都是付費的一個費用項，他們屬於一個實體或者服務商品
- 差異點是：實體商品，定製化服務可以被單獨售賣，但是運費服務是必然不會被單獨售賣。
按照這個抽象得出的結論是：
一個子訂單 = 有且僅有一個可被售賣的商品 + 多個不可被售賣的商品
不可被售賣的商品在一個訂單中通過費用項去表達，而不是通過訂單去表達。比如一個實體商品訂單的構成是：
sub_order_no + delivery_fee
在此基礎上清晰的解釋了一個子訂單是什麼。
現狀，未來，架構趨勢
結合得物的業務模式，訂單側現已有主子訂單的概念，並且在歷史交易資料中，都是一個主訂單有且僅有一個子訂單。
得物現今主流交易模型中，使用者下單時，存在以下特點：
- 只可購買一個商品
- 商品數量不可選擇，預設商品數量是 1
- 由於平臺存在質檢流程，從物流上看，買賣家無法直接交易，發貨和退貨都必須經過平臺中轉
- 未來一段時間內，多地開倉之前，平臺只有一個真實履約倉庫，發貨和退貨的中轉倉庫只有一個
根據以上主流交易場景，使用以下模型幾乎可以解決使用者下單時所遇到的所有問題：
- 一次提交訂單產生一筆主訂單
- 一次提交訂單單隻包含一個子訂單；主訂單包含子訂單；一個子訂單包含一種 SKU
- 一次提交訂單隻產生一個支付單
- 一次提交訂單隻產生一筆物流單
但沒有任何一家公司是一層不變的，未來，得物肯定會整合已有的業務模型，同時也會提出新的業務述求，大膽預測業務將朝以下幾個方向發展：
- 平臺在整個交易流程中仍是強介入，在一段時間內不太可能開放商家與買家直接交易。
- 合併支付或購物車需求會日益緊迫，舊模型中，使用者購買多個商品支付多筆運費的方式急需改善。
- 隨著訂單量的增長，多地開倉將是大勢所趨。物流有效合併將是趨勢。
為此舊模型需要一定程度上的擴充才可以繼續支撐業務發展。首先先大致分析下以上業務發展趨勢：
平臺在整個交易流程中強介入，與傳統電商模型有比較大的不同，淘寶，京東的交易提議中，店鋪的概念很強。在以下幾個方面買家都可以清晰的感知到店鋪的存在：
所以淘寶和京東的訂單大部分是店鋪為單位。主子訂單比較好切分，假如同一個店鋪下的所有購買行為作為主訂單，單類 SKU 作為子訂單，那麼主子訂單模型大致如下：
ps: 一種 SKU 在同一個店鋪下購買 M 份，當 M 大於 2 時，到底是以一個子訂單還是 M 個子訂單去承單待考量。
但是得物的交易模型中，商家，平臺，買家三方的作用都很強，平臺作為連結買家和賣家的紐帶，質檢和中轉賣家售賣和買家退貨，導致了訂單模型不可以簡單的按照店鋪為基本切分單位。借鑑於電商平臺主訂單的直觀對外展示，部分子訂單的聚合標準大致有以下幾個：
如果基於以上模型去考慮，那麼影響子訂單聚合的指標大概有：
如果基於以上的業務模型進行分析，進一步進行邏輯抽象，將【倉庫】【商家】【購買渠道】等等一系列統一抽象成【指標】，那麼系統的邏輯模型大致如下：M 個子訂單聚合成 N 個主訂單。
綜上所述: 主訂單是對使用者提交訂單成功後展示結果的抽象。
文/juven
關注得物技術，做最潮技術人！