概述
本文主要述說了在傳統電商企業中，訂單系統應承載的角色，就訂單系統所包含的主要功能模塊梳理了設計思路，并對訂單系統未來的發展做了一些思索。
1.訂單系統在企業中的角色
在搭建企業訂單系統之前，須要先梳理企業整體業務系統之間的關系和訂單系統上下游關系，只有界定清業務系統邊界，就能確定訂單系統的職責與功能，從而保證各系統之間高效簡約的工作。
2.訂單系統與各業務系統的關系
（1）對外系統：所有給企業外部用戶使用的系統都在這一層，包括官網、普通用戶使用的C端，還包括給商戶使用的店家后臺和在各個銷售渠道進行分銷的系統，例如與農行信用卡中心合作、微信合作在合作商的平臺漏出本企業的產品。這類系統站在與顧客接觸的最前線，是公司實現商業模式的橋頭堡。
（2）管理中后臺：每位C端的業務形態就會有一個對應的系統模塊，如負責管理平臺交易的訂單系統，管理讓利信息的促銷系統，管理平臺所有產品的產品系統，以及管理所有對外系統顯示內容的內容系統等。
（3）公共服務系統：隨著企業的發展，信息化建設抵達一定程度后，企業須要將通用功能服務化、平臺化，以保證應用構架的合理智，提高服務效率。這類系統主要給其他應用系統提供基礎服務能力支持。
3.訂單系統上下游關系
由此可見，訂單系統對上接收用戶信息，將用戶信息轉化為產品訂單，同時管理并跟蹤訂單信息和數據，承載了公司整個交易線的重要對客環節。對下則銜接產品系統、促銷系統、倉儲系統、會員系統、支付系統等，對整個電商平臺起著承上啟下的作用。
4.訂單系統的業務構架
（1）訂單服務該模塊的主要功能是用戶日常使用的服務和頁面，主要有訂單列表、訂單詳情、在線下單等，還包括為公共業務模塊提供的多維度訂單數據服務。
（2）訂單邏輯訂單系統的核心，起著至關重要的作用，在訂單系統負責管理訂單創建、訂單支付、訂單生產、訂單確認、訂單完成、取消訂單等訂單流程。還涉及到復雜的訂單狀態規則、訂單金額估算規則以及增減庫存規則等。在4節核心功能設計中會重點來說。
（3）底層服務信息化建設達到一定程度的企業，通常會將公司公共服務模塊化，例如：產品，會建立對應的產品系統，代碼、數據庫，插口等相對獨立。并且，這也帶來了一個問題，例如：訂單創建的場景下須要獲取的信息分散在各個系統。
假如須要從各個公共服務系統調用：一是會耗費大量時間，二是代碼的維護成本十分高。為此，訂單系統接入所需的公共服務模塊插口，在訂單系統即可完成對接公共系統的服務。
訂單系統核心功能1.訂單中所包含的內容信息
為了使訂單系統還能對訂單進行高效、精準的管理和跟蹤，訂單會存儲關于產品、優惠、用戶、支付信息等一系列的訂單實時數據，來和下游系統，如：促銷、倉儲、物流進行交互。
以一個通用B2C商城的訂單為例，梳理其包含的信息如下：
這兒要注意的是訂單類型，隨著平臺業務的不斷發展，品類豐富、交易方法豐富后，須要對訂單進行多維度的分類管理，同時訂單類型利于訂單系統的擴充性。每種訂單類型將會對應一套流程及一套狀態，以便對訂單進行分類管理和復用。
2.流程引擎
流程是指從平臺角度出發，將訂單從創建到完成的整個流轉過程進行具象，因而產生了一套標準流程規則。而不同的產品類型或交易類型在系統中的流程會千差萬別，因而為了便捷對訂單流程進行管理，會成立流程引擎模塊。
每套訂單流程中會包含正向流程及逆向流程，正向流程可以稱作一次順利的網購體驗過程中，后臺系統之間的信息流轉。逆向流程則是更改訂單、取消訂單、退款、退貨等各類動作導致的后臺系統流程，同時每位流程觸發的條件又可分為系統觸發和人工觸發兩種場景。
（1）正向流程
以一個通用B2C商城的訂單系統為例，依據其實際業務場景，其訂單流程可具象為5大步驟：訂單創建>訂單支付>訂單生產>訂單確認>訂單完成。
而每位步驟的背后，訂單是怎樣在多系統之間交互流轉的，可概括如右圖：
訂單創建：
用戶下單后，系統須要生成訂單，此時須要先獲取下單中涉及的商品信息，之后獲取該商品所涉及到的讓利信息，假如商品不參與讓利信息，則無此環節。
接著獲取該帳戶的會員權益，這兒要注意的是：讓利信息與會員權益的區別，例如：商品滿減是讓利信息，SUPER會員全場9.8折指的是會員權益，一個是針對商品，另一個是針對帳戶。其次就是讓利活動的疊加規則和優先級規則等。
增減庫存規則是指訂單中的商品，何時從倉儲系統中對相應商品庫存進行交納，目前主流有兩種形式：下單減庫存——即用戶下單成功時降低庫存數目
解決辦法：
設置訂單有效時間，若訂單創建成功N分鐘不付款，則訂單取消，庫存回滾；限貸，用各類條件來限制賣家的訂購件數，例如一個帳號、一個ip，只能買一件；風控，從技術角度進行判別，屏蔽惡意帳號，嚴禁惡意帳號訂購。
付款減庫存——即用戶支付完成并反饋給平臺后再降低庫存數目
解決辦法：
付款前再度校準庫存，如確認訂單要付款時再驗證一次，并友好提示用戶庫存不足；降低提示信息：在商品詳情頁，訂單步驟頁面提示不及時付款，不能保證有庫存等。
綜上所述，兩種方法各有優劣點，為此，需結合實際場景進行考慮，如：秒殺、搶購、促銷活動等，可使用下單減庫存的形式。
而對于產品庫存量大，并發流量沒有這么強的產品使用付款減庫存的形式。將兩種形式帶入到銷售場景中，關聯商品類型、促銷類型、供需關系等，靈活使用，以充分發揮計算機系統的優勢。
訂單支付：
用戶支付完訂單后，須要獲取訂單的支付信息，包括支付流水號、支付時間等。支付完訂單接著就是等店家發貨，但在發貨過程中，按照平臺業務模式的不同，可能會涉及到訂單的分拆。訂單分拆通常分兩種：
訂單分拆也是一個相對獨立的模塊，這兒就不詳盡描述了。
訂單生產：
訂單生產，是指產品從企業到用戶這一流程的概述。如電商平臺中，店家發貨過程已有一個標準化的流程，訂單內容會發送到庫房，庫房對商品進行打單、揀貨、包裝、交接快件進行配送。
訂單確認：
收到貨后，訂單系統須要在快件被簽收后提醒用戶對商品做評價。這兒要注意，確認收到貨不代表交易成功，相反是售后服務的開始。
訂單完成：
訂單完成是指在收到貨X天的狀態，此時訂單不在售后的支持時間范圍內。到此，一個訂單的正向流程即使走完了。
（2）逆向流程
里面說到逆向流程是各類更改訂單、取消訂單、退款、退貨等操作，須要梳理清楚這種流程與正向流程的關系，能夠理清訂單系統完整的訂單流程。
訂單更改：
可梳理訂單內信息，按照信息關聯程度及業務訴求，設定訂單的可更改范圍是哪些，例如：顧客下單后，想更改收件人地址及電話。此時只需對相應數據進行更新即可。
訂單取消：
用戶遞交訂單后沒有進行支付操作，此時用戶原則上屬于取消訂單，由于還未付款，則比較簡單，只須要將原先遞交訂單時扣減的庫存補回微信訂單系統，促銷讓利中使用的讓利券，權益等視平臺規則，進行相應補回。
退貨：
用戶支付成功后，顧客發出退貨的訴求后，需商戶進行退票初審，雙方達成一致后，系統應以退票單的方式完成退票，關聯原訂單數據。因商品無變化，所以不需考慮與庫存系統的交互，僅需考慮促銷系統及支付系統交互即可。
退款：用戶支付成功后，顧客發出退款的訴求后，需商戶進行退票初審，雙方達成一致后，需對庫存系統進行補回，支付系統、促銷系統以退票單方式完成退貨。最后，在退票/退款流程中，需結合平臺業務場景，考慮讓利均攤的邏輯，在發生退貨/退款時，讓利該怎么退回的處理規則和流程。
（3）狀態機
狀態機是管理訂單狀態邏輯的工具。狀態機可歸納為3個要素，即現態、動作、次態。
現態：是指當前所處的狀態。動作：動作執行完畢后，可以遷移到新的狀態，也可以仍然保持原狀態。次態：動作滿足后要搬到的新狀態，“次態”是相對于“現態”而言的，“次態”一旦被激活，就轉弄成新的“現態”了。
狀態機的設計須要結合平臺實際業務場景，將狀態間的切換細化成了執行了某個動作。以一個B2C商城的訂單系統舉例如下：
訂單系統為了高效的對訂單進行跟蹤和管理，會對訂單流程當中的關鍵節點，具象出訂單狀態。而訂單狀態從不同用戶的角度可分為，系統訂單狀態、商家訂單狀態、買家訂單狀態等。
對于訂單系統來說，訂單狀態細分的顆粒度越細、越明晰，訂單系統管理的精度和可靠性就越高，例如：在待付款和待發貨兩個狀態中，訂單系統后臺會細分為訂單超時取消、訂單支付失敗、訂單付款完成等。
因而，訂單狀態模塊中，一般會維護狀態映射表，以不同的用戶角色對系統訂單狀態進行重新界定，以滿足不同用戶的需求。
除此以外，隨著電商平臺的不斷發展，不同的業務類型，所對應的訂單狀態就會有所區別。所以，訂單系統中通常會存儲多套狀態機，以滿足不同的訂單類型來使用。
訂單系統的發展
訂單系統的主體框架，和主要業務模塊已基本講完，這么隨著企業的發展，業務量和業務方式不斷變化，企業有可能產生多個訂單系統并存以滿足不同的業務須要的情況。業務系統構架如下：
這些狀況的出現，將會給平臺帶來特別大的發展困局，如：
三個訂單系統，每位訂單系統處理不同類型的訂單，沒有統一的訂單銷量、訂單狀態信息，網站前臺對訂單的狀態展示與控制不統一，只能是在網站前臺會員中心硬代碼維護一套面向會員的統一訂單明細與狀態數據。而無線側上線后微信訂單系統，因為不了解前臺網站會員中心的訂單狀態管理邏輯，所以須要把前臺網站的訂單明細及狀態管理再在無線應用側再實現一遍。
三套后臺訂單系統與公共業務系統如會員中心、支付與財務、促銷工具、客戶分單等系統都須要對接一遍，公共業務處理邏輯不統一，一旦邏輯變更，多個系的同一個插口都要更改一遍，插口的重復維護開發工作量大。
訂單開發目前分到事業部，各個事業部只會考慮自己的邏輯，不會考慮公共構架，只會越走越遠。遇到像無線這樣的項目，須要對接各個事業部，無線側應用上線進展慢。
因而未來的訂單系統可分拆為訂單中心與業務訂單系統兩個模塊，以管理公司所有訂單數據，并為各個模塊提供統一服務。
最后
對于企業訂單系統的搭建，并不是要做的大而全、也不是要小而精。而須要結合市場、公司、業務的實際情況來最終制訂系統設計方案和產品迭代計劃。最終，和公司整體發展互相協調，相輔相成。
免責聲明：部分文章信息來源于網絡以及網友投稿，本站只負責對文章進行整理、排版、編輯，出于傳遞更多信息之目的，并不意味著贊同其觀點或證實其內容的真實性，如本站文章和轉稿涉及版權等問題，請作者在及時聯系本站，我們會盡快為您處理。
