還不知道，如何設計訂單系統？來看這篇文章，很不錯！

本文主要講述了在傳統電商企業中，訂單系統應承載的角色，就訂單系統所包含的主要功能模塊梳理了設計思路，並對訂單系統將來的發展作了一些思考。

1. 訂單系統在企業中的角色

在搭建企業訂單系統以前，須要先梳理企業總體業務系統之間的關係和訂單系統上下游關係，只有劃分清業務系統邊界，才能肯定訂單系統的職責與功能，進而保證各系統之間高效簡潔的工做。

2. 訂單系統與各業務系統的關係

（1）對外系統：

全部給企業外部用戶使用的系統都在這一層，包括官網、普通用戶使用的C端，還包括給商戶使用的商家後臺和在各個銷售渠道進行分銷的系統，好比與銀行信用卡中心合做、微信合做在合做商的平臺露出本企業的產品。這類系統站在與客戶接觸的最前線，是公司實現商業模式的橋頭堡。

（2）管理中後臺：

每一個C端的業務形態都會有一個對應的系統模塊，如負責管理平臺交易的訂單系統，管理優惠信息的促銷系統，管理平臺全部產品的產品系統，以及管理全部對外系統顯示內容的內容系統等。

（3）公共服務系統：

隨着企業的發展，信息化建設到達必定程度後，企業須要將通用功能服務化、平臺化，以保證應用架構的合理性，提高服務效率。這類系統主要給其餘應用系統提供基礎服務能力支持。關注公衆號：程序員白楠楠， 領取2020最新Java面試題手冊（200多頁PDF文檔）。

3. 訂單系統上下游關係

因而可知，訂單系統對上接收用戶信息，將用戶信息轉化爲產品訂單，同時管理並跟蹤訂單信息和數據，承載了公司整個交易線的重要對客環節。對下則銜接產品系統、促銷系統、倉儲系統、會員系統、支付系統等，對整個電商平臺起着承上啓下的做用。

4. 訂單系統的業務架構

（1）訂單服務

該模塊的主要功能是用戶平常使用的服務和頁面，主要有訂單列表、訂單詳情、在線下單等，還包括爲公共業務模塊提供的多維度訂單數據服務。

（2）訂單邏輯

訂單系統的核心，起着相當重要的做用，在訂單系統負責管理訂單建立、訂單支付、訂單生產、訂單確認、訂單完成、取消訂單等訂單流程。還涉及到複雜的訂單狀態規則、訂單金額計算規則以及增減庫存規則等。在4節核心功能設計中會重點來講。

（3）底層服務

信息化建設達到必定程度的企業，通常會將公司公共服務模塊化，好比：產品，會構建對應的產品系統，代碼、數據庫，接口等相對獨立。可是，這也帶來了一個問題，好比：訂單建立的場景下須要獲取的信息分散在各個系統。

若是須要從各個公共服務系統調用：一是會花費大量時間，二是代碼的維護成本很是高。所以，訂單系統接入所需的公共服務模塊接口，在訂單系統便可完成對接公共系統的服務。

訂單系統核心功能

1. 訂單中所包含的內容信息

爲了使訂單系統可以對訂單進行高效、精準的管理和跟蹤，訂單會儲存關於產品、優惠、用戶、支付信息等一系列的訂單實時數據，來和下游系統，如：促銷、倉儲、物流進行交互。

以一個通用B2C商城的訂單爲例，梳理其包含的信息以下：

這裏要注意的是訂單類型，隨着平臺業務的不斷髮展，品類豐富、交易方式豐富後，須要對訂單進行多維度的分類管理，同時訂單類型利於訂單系統的擴展性。每種訂單類型將會對應一套流程及一套狀態，便於對訂單進行分類管理和複用。

2. 流程引擎

流程是指從平臺角度出發，將訂單從建立到完成的整個流轉過程進行抽象，從而造成了一套標準流程規則。而不一樣的產品類型或交易類型在系統中的流程會千差萬別，所以爲了方便對訂單流程進行管理，會組建流程引擎模塊。

每套訂單流程中會包含正向流程及逆向流程，正向流程能夠比做一次順利的網購體驗過程當中，後臺系統之間的信息流轉。逆向流程則是修改訂單、取消訂單、退款、退貨等各類動做引發的後臺系統流程，同時每一個流程觸發的條件又可分爲系統觸發和人工觸發兩種場景。關注公衆號：程序員白楠楠， 領取2020最新Java面試題手冊（200多頁PDF文檔）。

（1）正向流程

以一個通用B2C商城的訂單系統爲例，根據其實際業務場景，其訂單流程可抽象爲5大步驟：訂單建立>訂單支付>訂單生產>訂單確認>訂單完成。

而每一個步驟的背後，訂單是如何在多系統之間交互流轉的，可歸納以下圖：

訂單建立：

用戶下單後，系統須要生成訂單，此時須要先獲取下單中涉及的商品信息，而後獲取該商品所涉及到的優惠信息，若是商品不參與優惠信息，則無此環節。

接着獲取該帳戶的會員權益，這裏要注意的是：優惠信息與會員權益的區別，好比：商品滿減是優惠信息，SUPER會員全場9.8折指的是會員權益，一個是針對商品，另外一個是針對帳戶。其次就是優惠活動的疊加規則和優先級規則等。

增減庫存規則是指訂單中的商品，什麼時候從倉儲系統中對相應商品庫存進行扣除，目前主流有兩種方式：

下單減庫存——即用戶下單成功時減小庫存數量

• 優點：用戶體驗友好，系統邏輯簡潔；

• 缺點：會致使惡意下單或下單後卻不買，使得真正有需求的用戶沒法購買，影響真實銷量；

解決辦法：

1. 設置訂單有效時間，若訂單建立成功N分鐘不付款，則訂單取消，庫存回滾；

2. 限購，用各類條件來限制買家的購買件數，好比一個帳號、一個ip，只能買一件；

3. 風控，從技術角度進行判斷，屏蔽惡意帳號，禁止惡意帳號購買。

付款減庫存——即用戶支付完成並反饋給平臺後再減小庫存數量

• 優點：減小無效訂單帶來的資源損耗；

• 缺點：因第三方支付返回結果存在時差，同一時間多個用戶同時付款成功，會致使下單數目超過庫存，商家庫存不足容易引起斷貨和投訴，成本增長。

解決辦法：

1. 付款前再次校驗庫存，如確認訂單要付款時再驗證一次，並友好提示用戶庫存不足；

2. 增長提示信息：在商品詳情頁，訂單步驟頁面提示不及時付款，不能保證有庫存等。

綜上所述，兩種方式各有優缺點，所以，需結合實際場景進行考慮，如：秒殺、搶購、促銷活動等，可以使用下單減庫存的方式。而對於產品庫存量大，併發流量沒有那麼強的產品使用付款減庫存的方式。

將兩種方式帶入到銷售場景中，關聯商品類型、促銷類型、供需關係等，靈活使用，以充分發揮計算機系統的優點。

訂單支付：

用戶支付完訂單後，須要獲取訂單的支付信息，包括支付流水號、支付時間等。支付完訂單接着就是等商家發貨，但在發貨過程當中，根據平臺業務模式的不一樣，可能會涉及到訂單的拆分。

訂單拆分通常分兩種：

• 一種是用戶挑選的商品來自於不一樣渠道（自營與商家，商家與商家）；

• 另外一種是在SKU層面上拆分訂單：不一樣倉庫，不一樣運輸要求的SKU，包裹重量體積限制等因素須要將訂單拆分。

訂單拆分也是一個相對獨立的模塊，這裏就不詳細描述了。

訂單生產：訂單生產，是指產品從企業到用戶這一流程的概述。如電商平臺中，商家發貨過程已有一個標準化的流程，訂單內容會發送到倉庫，倉庫對商品進行打單、揀貨、包裝、交接快遞進行配送。

訂單確認：收到貨後，訂單系統須要在快遞被簽收後提醒用戶對商品作評價。這裏要注意，確認收到貨不表明交易成功，相反是售後服務的開始。

訂單完成：訂單完成是指在收到貨X天的狀態，此時訂單不在售後的支持時間範圍內。到此，一個訂單的正向流程就算走完了。

（2）逆向流程

上面說到逆向流程是各類修改訂單、取消訂單、退款、退貨等操做，須要梳理清楚這些流程與正向流程的關係，才能理清訂單系統完整的訂單流程。

訂單修改：可梳理訂單內信息，根據信息關聯程度及業務訴求，設定訂單的可修改範圍是什麼，好比：客戶下單後，想修改收貨人地址及電話。此時只需對相應數據進行更新便可。

訂單取消：用戶提交訂單後沒有進行支付操做，此時用戶原則上屬於取消訂單，由於還未付款，則比較簡單，只須要將本來提交訂單時扣減的庫存補回，促銷優惠中使用的優惠券，權益等視平臺規則，進行相應補回。

退款：用戶支付成功後，客戶發出退款的訴求後，需商戶進行退款審覈，雙方達成一致後，系統應以退款單的形式完成退款，關聯原訂單數據。因商品無變化，因此不需考慮與庫存系統的交互，僅需考慮促銷系統及支付系統交互便可。

退貨：用戶支付成功後，客戶發出退貨的訴求後，需商戶進行退款審覈，雙方達成一致後，需對庫存系統進行補回，支付系統、促銷系統以退款單形式完成退款。最後，在退款/退貨流程中，需結合平臺業務場景，考慮優惠分攤的邏輯，在發生退款/退貨時，優惠該如何退回的處理規則和流程。

（3）狀態機

狀態機是管理訂單狀態邏輯的工具。狀態機可概括爲3個要素，即現態、動做、次態。

1. 現態：是指當前所處的狀態。

2. 動做：動做執行完畢後，能夠遷移到新的狀態，也能夠仍舊保持原狀態。

3. 次態：動做知足後要遷往的新狀態，「次態」是相對於「現態」而言的，「次態」一旦被激活，就轉變成新的「現態」了。

狀態機的設計須要結合平臺實際業務場景，將狀態間的切換細化成了執行了某個動做。

以一個B2C商城的訂單系統舉例以下：

訂單系統爲了高效的對訂單進行跟蹤和管理，會對訂單流程當中的關鍵節點，抽象出訂單狀態。而訂單狀態從不一樣用戶的角度可分爲，系統訂單狀態、商家訂單狀態、買家訂單狀態等。

對於訂單系統來講，訂單狀態細分的顆粒度越細、越明確，訂單系統管理的精度和可靠性就越高，好比：在待付款和待發貨兩個狀態中，訂單系統後臺會細分爲訂單超時取消、訂單支付失敗、訂單付款完成等。

所以，訂單狀態模塊中，一般會維護狀態映射表，以不一樣的用戶角色對系統訂單狀態進行從新劃分，以知足不一樣用戶的需求。

除此之外，隨着電商平臺的不斷髮展，不一樣的業務類型，所對應的訂單狀態都會有所區別。因此，訂單系統中通常會儲存多套狀態機，以知足不一樣的訂單類型來使用。

訂單系統的發展

訂單系統的主體框架，和主要業務模塊已基本講完，那麼隨着企業的發展，業務量和業務形式不斷變化，企業有可能造成多個訂單系統並存以知足不一樣的業務須要的狀況。

業務系統架構以下：

這種情況的出現，將會給平臺帶來很是大的發展瓶頸，如：

三個訂單系統，每一個訂單系統處理不一樣類型的訂單，沒有統一的訂單銷量、訂單狀態信息，網站前臺對訂單的狀態展現與控制不統一，只能是在網站前臺會員中心硬代碼維護一套面向會員的統一訂單明細與狀態數據。而無線側上線後，因爲不瞭解前臺網站會員中心的訂單狀態管理邏輯，因此須要把前臺網站的訂單明細及狀態管理再在無線應用側再實現一遍。

三套後臺訂單系統與公共業務系統如會員中心、支付與財務、促銷工具、客戶分單等系統都須要對接一遍，公共業務處理邏輯不統一，一旦邏輯變動，多個系的同一個接口都要修改一遍，接口的重複維護開發工做量大。

訂單開發目前分到事業部，各個事業部只會考慮本身的邏輯，不會考慮公共架構，只會越走越遠。碰到像無線這樣的項目，須要對接各個事業部，無線側應用上線進展慢。

所以將來的訂單系統可拆分爲訂單中心與業務訂單系統兩個模塊，以管理公司全部訂單數據，併爲各個模塊提供統一服務。

最後

對於企業訂單系統的搭建，並非要作的大而全、也不是要小而精。而須要結合市場、公司、業務的實際狀況來最終制定系統設計方案和產品迭代計劃。

最終，和公司總體發展相互協調，相輔相成。

關注公衆號：程序員白楠楠， 領取2020最新Java面試題手冊（200多頁PDF文檔）。