前言
在電商系統中，訂單系統往往承載着非常重要的角色。在極光商城項目的準備階段，最耗費我時長的就是訂單系統了（畢竟實力也不咋樣。這期間我也查閱了大量資料，為這一塊的設計做了些準備。隻能說第一次設計，還是挺想做出個好東西來，但是這要考慮的東西，可比單純的寫業務代碼要多得多了呀。
業務關系
訂單系統
先來看看訂單系統在整個極光商城中扮演的角色，實際上是負責管理平台交易的訂單處理系統。
訂單管理
訂單管理子產品，主要的展現就是在背景的訂單管理子產品了。主要功能為訂單清單、訂單詳情、訂單定時任務、訂單操作、訂單跟蹤、訂單售後、訂單流水等。
訂單服務
訂單服務子產品，為整個商城的業務支撐，負責的業務也是較複雜的。主要有訂單建立，訂單支付、訂單确認、取消訂單、發起售後、訂單跟蹤等流程。其中的規則較為複雜，比如說在使用者送出訂單時，得根據相應的規則判斷訂單是否合法，也可以了解為風控吧。然後要計算訂單的金額，購買了東西，相應的庫存也要變化，還要考慮超賣問題。其中某些步驟可能是需要異步調用的，舉個例子：我用12306買票時，付款後，先收到郵件，然後12306APP這邊的狀态過幾秒鐘能看到購買成功，這裡發郵件的功能，可能就是用的異步調用。
訂單資訊
整個訂單的設計，是采取的主表和子表。主表主要會存放訂單的基本資訊、使用者資訊、訂單流水，物流資訊、促銷資訊、等。但是考慮到一個訂單可能包含多個商品，是以說子訂單就是用來存放這些不同商品的資訊的，當然，也可以進行訂單拆分業務，但是即使這麼設計，也要考慮到使用者隻應該付一次款的問題。
資料庫設計
資料庫裡面，目前隻對訂單系統設計了6張表，以目前的業務來看的話，是綽綽有餘了，以後業務變更了再修改吧。
訂單流程
就以正常下單的流程來說吧，售後的訂單這裡就不過多介紹了。
訂單建立
使用者登入商城，挑選想要購買的商品，然後選擇位址和促銷資訊并送出訂單。然後生成訂單前，我們需要擷取使用者資訊、商品資訊、促銷資訊等。當然，并不是所有的資料都從前端接收的，不然的話使用者傳個假的價格過來，豈不是0元購了????。擷取完資訊後，這時背景的風控系統，可以進行一系列的規則校驗。咱們還得判斷庫存吧，庫存不夠了也不能賣，這裡的業務設計，以送出訂單為準進行庫存的扣除。最後生成訂單資訊和支付資訊，同步目前訂單即建立完成。
訂單支付
支付的話，肯定就是對接第三方平台做一個支付功能了，具體的可以去看支付寶開放平台的文檔做個參考。這裡主要闡述下訂單拆分問題。根據訂單裡面的商品的性質等原因，可以進行不同的訂單拆分。但是，訂單建議設計成同時支付和綁定訂單。不然的話，很容易被湊單，進而造成一定的損失。除非你的業務就是想弄成淘寶那種，為了湊單拼到300元，然後付款了秒退湊單商品，進而達到優惠的效果。最後根據訂單支付的結果，對訂單進行操作，成功了就走訂單生産流程，失敗了就走失敗訂單的流程，還原被扣除的庫存。
訂單生産
如果有多個倉庫，可根據使用者收貨位址等因素來調配倉庫的貨物。并将商品打包寄出，同時更新快遞狀态實時同步。
訂單完成
使用者收到商品後，确認收貨，訂單至此完成。
使用者體驗
在訂單的整個生命周期，都可以通過消息隊列來異步操作。比如訂單狀态更新了，可以給使用者發郵件或者短信通知，在商城系統的使用者中心也可以推送通知等。
最後
将訂單系統進行拆分，也就是訂單的管理和訂單的處理這兩個子產品是分開的。主要是考慮到使用者下單，和客服進行訂單管理的業務差別有點大，前者操作很頻繁，後者可能更多的隻是看看，做的操作較少。雖然移動端我現在還不會開發，但是得想到一個問題，不同的平台，對應的訂單系統的處理邏輯肯定無法保證100%相同的。那麼将邏輯拆分，統一管理，我覺得可能是較好的一個方案（目前也隻能想到這一步了????），腳踏實地，一步步來吧，畢竟自己要學的東西也很多。