來自：人人都是產(chǎn)品經(jīng)理
作者：sleeping
鏈接： http://www.woshipm.com/pd/1392102.html
概述
本文主要講述了在傳統(tǒng)電商企業(yè)中顿涣，訂單系統(tǒng)應(yīng)承載的角色为迈，就訂單系統(tǒng)所包含的主要功能模塊梳理了設(shè)計思路，并對訂單系統(tǒng)未來的發(fā)展做了一些思考键闺。
1、訂單系統(tǒng)在企業(yè)中的角色
在搭建企業(yè)訂單系統(tǒng)之前惨撇，需要先梳理企業(yè)整體業(yè)務(wù)系統(tǒng)之間的關(guān)系和訂單系統(tǒng)上下游關(guān)系创坞，只有劃分清業(yè)務(wù)系統(tǒng)邊界，才能確定訂單系統(tǒng)的職責(zé)與功能凤优，進而保證各系統(tǒng)之間高效簡潔的工作悦陋。
2、訂單系統(tǒng)與各業(yè)務(wù)系統(tǒng)的關(guān)系
（1）對外系統(tǒng)：
所有給企業(yè)外部用戶使用的系統(tǒng)都在這一層筑辨，包括官網(wǎng)俺驶、普通用戶使用的C端，還包括給商戶使用的商家后臺和在各個銷售渠道進行分銷的系統(tǒng)棍辕，比如與銀行信用卡中心合作暮现、微信合作在合作商的平臺露出本企業(yè)的產(chǎn)品。這類系統(tǒng)站在與客戶接觸的最前線楚昭，是公司實現(xiàn)商業(yè)模式的橋頭堡栖袋。
（2）管理中后臺：
每個C端的業(yè)務(wù)形態(tài)都會有一個對應(yīng)的系統(tǒng)模塊，如負責(zé)管理平臺交易的訂單系統(tǒng)抚太，管理優(yōu)惠信息的促銷系統(tǒng)塘幅，管理平臺所有產(chǎn)品的產(chǎn)品系統(tǒng)，以及管理所有對外系統(tǒng)顯示內(nèi)容的內(nèi)容系統(tǒng)等尿贫。
（3）公共服務(wù)系統(tǒng)：
隨著企業(yè)的發(fā)展电媳，信息化建設(shè)到達一定程度后，企業(yè)需要將通用功能服務(wù)化庆亡、平臺化匾乓，以保證應(yīng)用架構(gòu)的合理性，提升服務(wù)效率又谋。這類系統(tǒng)主要給其他應(yīng)用系統(tǒng)提供基礎(chǔ)服務(wù)能力支持钝尸。
3、訂單系統(tǒng)上下游關(guān)系
由此可見搂根，訂單系統(tǒng)對上接收用戶信息，將用戶信息轉(zhuǎn)化為產(chǎn)品訂單铃辖，同時管理并跟蹤訂單信息和數(shù)據(jù)剩愧，承載了公司整個交易線的重要對客環(huán)節(jié)。對下則銜接產(chǎn)品系統(tǒng)娇斩、促銷系統(tǒng)仁卷、倉儲系統(tǒng)穴翩、會員系統(tǒng)、支付系統(tǒng)等锦积，對整個電商平臺起著承上啟下的作用芒帕。
4、訂單系統(tǒng)的業(yè)務(wù)架構(gòu)
（1）訂單服務(wù)
該模塊的主要功能是用戶日常使用的服務(wù)和頁面丰介，主要有訂單列表背蟆、訂單詳情、在線下單等哮幢，還包括為公共業(yè)務(wù)模塊提供的多維度訂單數(shù)據(jù)服務(wù)带膀。
（2）訂單邏輯
訂單系統(tǒng)的核心，起著至關(guān)重要的作用橙垢，在訂單系統(tǒng)負責(zé)管理訂單創(chuàng)建垛叨、訂單支付、訂單生產(chǎn)柜某、訂單確認嗽元、訂單完成、取消訂單等訂單流程喂击。還涉及到復(fù)雜的訂單狀態(tài)規(guī)則剂癌、訂單金額計算規(guī)則以及增減庫存規(guī)則等。在4節(jié)核心功能設(shè)計中會重點來說惭等。
（3）底層服務(wù)
信息化建設(shè)達到一定程度的企業(yè)珍手，一般會將公司公共服務(wù)模塊化，比如：產(chǎn)品辞做，會構(gòu)建對應(yīng)的產(chǎn)品系統(tǒng)琳要，代碼、數(shù)據(jù)庫秤茅，接口等相對獨立稚补。但是，這也帶來了一個問題框喳，比如：訂單創(chuàng)建的場景下需要獲取的信息分散在各個系統(tǒng)课幕。
如果需要從各個公共服務(wù)系統(tǒng)調(diào)用：一是會花費大量時間，二是代碼的維護成本非常高五垮。因此乍惊，訂單系統(tǒng)接入所需的公共服務(wù)模塊接口，在訂單系統(tǒng)即可完成對接公共系統(tǒng)的服務(wù)放仗。
訂單系統(tǒng)核心功能
1润绎、訂單中所包含的內(nèi)容信息
為了使訂單系統(tǒng)能夠?qū)τ唵芜M行高效、精準的管理和跟蹤，訂單會儲存關(guān)于產(chǎn)品莉撇、優(yōu)惠呢蛤、用戶、支付信息等一系列的訂單實時數(shù)據(jù)棍郎，來和下游系統(tǒng)其障，如：促銷、倉儲涂佃、物流進行交互励翼。
以一個通用B2C商城的訂單為例，梳理其包含的信息如下：
這里要注意的是訂單類型巡李，隨著平臺業(yè)務(wù)的不斷發(fā)展抚笔，品類豐富、交易方式豐富后侨拦，需要對訂單進行多維度的分類管理殊橙，同時訂單類型利于訂單系統(tǒng)的擴展性。每種訂單類型將會對應(yīng)一套流程及一套狀態(tài)狱从，便于對訂單進行分類管理和復(fù)用膨蛮。
2、流程引擎
流程是指從平臺角度出發(fā)季研，將訂單從創(chuàng)建到完成的整個流轉(zhuǎn)過程進行抽象敞葛，從而形成了一套標準流程規(guī)則。而不同的產(chǎn)品類型或交易類型在系統(tǒng)中的流程會千差萬別与涡，因此為了方便對訂單流程進行管理惹谐，會組建流程引擎模塊。
每套訂單流程中會包含正向流程及逆向流程驼卖，正向流程可以比作一次順利的網(wǎng)購體驗過程中氨肌，后臺系統(tǒng)之間的信息流轉(zhuǎn)。逆向流程則是修改訂單酌畜、取消訂單怎囚、退款、退貨等各種動作引起的后臺系統(tǒng)流程桥胞，同時每個流程觸發(fā)的條件又可分為系統(tǒng)觸發(fā)和人工觸發(fā)兩種場景恳守。
（1）正向流程
以一個通用B2C商城的訂單系統(tǒng)為例，根據(jù)其實際業(yè)務(wù)場景贩虾，其訂單流程可抽象為5大步驟：訂單創(chuàng)建>訂單支付>訂單生產(chǎn)>訂單確認>訂單完成催烘。
而每個步驟的背后，訂單是如何在多系統(tǒng)之間交互流轉(zhuǎn)的缎罢，可概括如下圖：
訂單創(chuàng)建：
用戶下單后颗圣，系統(tǒng)需要生成訂單喳钟，此時需要先獲取下單中涉及的商品信息，然后獲取該商品所涉及到的優(yōu)惠信息在岂，如果商品不參與優(yōu)惠信息，則無此環(huán)節(jié)蛮寂。
接著獲取該賬戶的會員權(quán)益蔽午，這里要注意的是：優(yōu)惠信息與會員權(quán)益的區(qū)別，比如：商品滿減是優(yōu)惠信息酬蹋，SUPER會員全場9.8折指的是會員權(quán)益及老，一個是針對商品，另一個是針對賬戶范抓。其次就是優(yōu)惠活動的疊加規(guī)則和優(yōu)先級規(guī)則等骄恶。
增減庫存規(guī)則是指訂單中的商品，何時從倉儲系統(tǒng)中對相應(yīng)商品庫存進行扣除匕垫，目前主流有兩種方式：
下單減庫存——即用戶下單成功時減少庫存數(shù)量
優(yōu)勢：用戶體驗友好僧鲁，系統(tǒng)邏輯簡潔；
缺點：會導(dǎo)致惡意下單或下單后卻不買象泵，使得真正有需求的用戶無法購買寞秃，影響真實銷量；
解決辦法：
設(shè)置訂單有效時間偶惠，若訂單創(chuàng)建成功N分鐘不付款春寿，則訂單取消，庫存回滾忽孽；
限購绑改，用各種條件來限制買家的購買件數(shù)，比如一個賬號兄一、一個ip厘线，只能買一件；
風(fēng)控瘾腰，從技術(shù)角度進行判斷皆的，屏蔽惡意賬號，禁止惡意賬號購買蹋盆。
付款減庫存——即用戶支付完成并反饋給平臺后再減少庫存數(shù)量
優(yōu)勢：減少無效訂單帶來的資源損耗费薄；
缺點：因第三方支付返回結(jié)果存在時差，同一時間多個用戶同時付款成功栖雾，會導(dǎo)致下單數(shù)目超過庫存楞抡，商家?guī)齑娌蛔闳菀滓l(fā)斷貨和投訴，成本增加析藕。
解決辦法：
付款前再次校驗庫存召廷，如確認訂單要付款時再驗證一次，并友好提示用戶庫存不足；
增加提示信息：在商品詳情頁竞慢，訂單步驟頁面提示不及時付款先紫，不能保證有庫存等。
綜上所述筹煮，兩種方式各有優(yōu)缺點遮精，因此，需結(jié)合實際場景進行考慮败潦，如：秒殺本冲、搶購、促銷活動等劫扒，可使用下單減庫存的方式檬洞。而對于產(chǎn)品庫存量大，并發(fā)流量沒有那么強的產(chǎn)品使用付款減庫存的方式沟饥。
將兩種方式帶入到銷售場景中添怔，關(guān)聯(lián)商品類型、促銷類型闷板、供需關(guān)系等澎灸，靈活使用，以充分發(fā)揮計算機系統(tǒng)的優(yōu)勢遮晚。
訂單支付：
用戶支付完訂單后性昭，需要獲取訂單的支付信息，包括支付流水號县遣、支付時間等糜颠。支付完訂單接著就是等商家發(fā)貨，但在發(fā)貨過程中萧求，根據(jù)平臺業(yè)務(wù)模式的不同其兴，可能會涉及到訂單的拆分。
訂單拆分一般分兩種：
一種是用戶挑選的商品來自于不同渠道（自營與商家夸政，商家與商家）元旬；
另一種是在SKU層面上拆分訂單：不同倉庫，不同運輸要求的SKU守问，包裹重量體積限制等因素需要將訂單拆分匀归。
訂單拆分也是一個相對獨立的模塊，這里就不詳細描述了耗帕。
訂單生產(chǎn)：訂單生產(chǎn)穆端，是指產(chǎn)品從企業(yè)到用戶這一流程的概述。如電商平臺中仿便，商家發(fā)貨過程已有一個標準化的流程体啰，訂單內(nèi)容會發(fā)送到倉庫攒巍，倉庫對商品進行打單、揀貨荒勇、包裝柒莉、交接快遞進行配送。
訂單確認：收到貨后枕屉，訂單系統(tǒng)需要在快遞被簽收后提醒用戶對商品做評價常柄。這里要注意，確認收到貨不代表交易成功搀擂，相反是售后服務(wù)的開始。
訂單完成：訂單完成是指在收到貨X天的狀態(tài)卷玉，此時訂單不在售后的支持時間范圍內(nèi)哨颂。到此，一個訂單的正向流程就算走完了相种。
（2）逆向流程
上面說到逆向流程是各種修改訂單威恼、取消訂單、退款寝并、退貨等操作箫措，需要梳理清楚這些流程與正向流程的關(guān)系，才能理清訂單系統(tǒng)完整的訂單流程衬潦。
訂單修改：可梳理訂單內(nèi)信息斤蔓，根據(jù)信息關(guān)聯(lián)程度及業(yè)務(wù)訴求，設(shè)定訂單的可修改范圍是什么镀岛，比如：客戶下單后弦牡，想修改收貨人地址及電話。此時只需對相應(yīng)數(shù)據(jù)進行更新即可漂羊。
訂單取消：用戶提交訂單后沒有進行支付操作驾锰，此時用戶原則上屬于取消訂單，因為還未付款走越，則比較簡單椭豫，只需要將原本提交訂單時扣減的庫存補回，促銷優(yōu)惠中使用的優(yōu)惠券旨指，權(quán)益等視平臺規(guī)則赏酥，進行相應(yīng)補回。
退款：用戶支付成功后淤毛，客戶發(fā)出退款的訴求后今缚，需商戶進行退款審核，雙方達成一致后低淡，系統(tǒng)應(yīng)以退款單的形式完成退款姓言，關(guān)聯(lián)原訂單數(shù)據(jù)瞬项。因商品無變化，所以不需考慮與庫存系統(tǒng)的交互何荚，僅需考慮促銷系統(tǒng)及支付系統(tǒng)交互即可囱淋。
退貨：用戶支付成功后，客戶發(fā)出退貨的訴求后餐塘，需商戶進行退款審核妥衣，雙方達成一致后，需對庫存系統(tǒng)進行補回戒傻，支付系統(tǒng)税手、促銷系統(tǒng)以退款單形式完成退款。最后需纳，在退款/退貨流程中芦倒，需結(jié)合平臺業(yè)務(wù)場景，考慮優(yōu)惠分攤的邏輯不翩，在發(fā)生退款/退貨時兵扬，優(yōu)惠該如何退回的處理規(guī)則和流程。
（3）狀態(tài)機
狀態(tài)機是管理訂單狀態(tài)邏輯的工具口蝠。狀態(tài)機可歸納為3個要素器钟，即現(xiàn)態(tài)、動作妙蔗、次態(tài)傲霸。
現(xiàn)態(tài)：是指當(dāng)前所處的狀態(tài)。
動作：動作執(zhí)行完畢后灭必，可以遷移到新的狀態(tài)狞谱，也可以仍舊保持原狀態(tài)。
次態(tài)：動作滿足后要遷往的新狀態(tài)禁漓，“次態(tài)”是相對于“現(xiàn)態(tài)”而言的跟衅，“次態(tài)”一旦被激活，就轉(zhuǎn)變成新的“現(xiàn)態(tài)”了播歼。
狀態(tài)機的設(shè)計需要結(jié)合平臺實際業(yè)務(wù)場景伶跷，將狀態(tài)間的切換細化成了執(zhí)行了某個動作。
以一個B2C商城的訂單系統(tǒng)舉例如下：
訂單系統(tǒng)為了高效的對訂單進行跟蹤和管理秘狞，會對訂單流程當(dāng)中的關(guān)鍵節(jié)點叭莫，抽象出訂單狀態(tài)。而訂單狀態(tài)從不同用戶的角度可分為烁试，系統(tǒng)訂單狀態(tài)雇初、商家訂單狀態(tài)、買家訂單狀態(tài)等减响。
對于訂單系統(tǒng)來說靖诗，訂單狀態(tài)細分的顆粒度越細郭怪、越明確，訂單系統(tǒng)管理的精度和可靠性就越高刊橘，比如：在待付款和待發(fā)貨兩個狀態(tài)中鄙才，訂單系統(tǒng)后臺會細分為訂單超時取消、訂單支付失敗促绵、訂單付款完成等攒庵。
因此，訂單狀態(tài)模塊中败晴，通常會維護狀態(tài)映射表浓冒，以不同的用戶角色對系統(tǒng)訂單狀態(tài)進行重新劃分，以滿足不同用戶的需求尖坤。
除此以外裆蒸，隨著電商平臺的不斷發(fā)展，不同的業(yè)務(wù)類型糖驴，所對應(yīng)的訂單狀態(tài)都會有所區(qū)別。所以佛致，訂單系統(tǒng)中一般會儲存多套狀態(tài)機贮缕，以滿足不同的訂單類型來使用。
訂單系統(tǒng)的發(fā)展
訂單系統(tǒng)的主體框架俺榆，和主要業(yè)務(wù)模塊已基本講完感昼，那么隨著企業(yè)的發(fā)展，業(yè)務(wù)量和業(yè)務(wù)形式不斷變化罐脊，企業(yè)有可能形成多個訂單系統(tǒng)并存以滿足不同的業(yè)務(wù)需要的情況定嗓。
業(yè)務(wù)系統(tǒng)架構(gòu)如下：
這種狀況的出現(xiàn)，將會給平臺帶來非常大的發(fā)展瓶頸萍桌，如：
三個訂單系統(tǒng)宵溅，每個訂單系統(tǒng)處理不同類型的訂單，沒有統(tǒng)一的訂單銷量上炎、訂單狀態(tài)信息恃逻，網(wǎng)站前臺對訂單的狀態(tài)展示與控制不統(tǒng)一，只能是在網(wǎng)站前臺會員中心硬代碼維護一套面向會員的統(tǒng)一訂單明細與狀態(tài)數(shù)據(jù)藕施。而無線側(cè)上線后寇损，由于不了解前臺網(wǎng)站會員中心的訂單狀態(tài)管理邏輯，所以需要把前臺網(wǎng)站的訂單明細及狀態(tài)管理再在無線應(yīng)用側(cè)再實現(xiàn)一遍裳食。
三套后臺訂單系統(tǒng)與公共業(yè)務(wù)系統(tǒng)如會員中心矛市、支付與財務(wù)、促銷工具诲祸、客戶分單等系統(tǒng)都需要對接一遍浊吏，公共業(yè)務(wù)處理邏輯不統(tǒng)一而昨，一旦邏輯變更多個系統(tǒng)統(tǒng)一個接口都要修改一遍，接口的重復(fù)維護開發(fā)工作量大卿捎。
訂單開發(fā)目前分到事業(yè)部配紫，各個事業(yè)部只會考慮自己的邏輯，不會考慮公共架構(gòu)午阵，只會越走越遠躺孝。碰到像無線這樣的項目，需要對接各個事業(yè)部底桂，無線側(cè)應(yīng)用上線進展慢植袍。
因此未來的訂單系統(tǒng)可拆分為訂單中心與業(yè)務(wù)訂單系統(tǒng)兩個模塊，以管理公司所有訂單數(shù)據(jù)籽懦，并為各個模塊提供統(tǒng)一服務(wù)缕溉。
業(yè)務(wù)系統(tǒng)架構(gòu)如下：
最后
對于企業(yè)訂單系統(tǒng)的搭建篱竭，并不是要做的大而全、也不是要小而精。而需要結(jié)合市場膜赃、公司、業(yè)務(wù)的實際情況來最終制定系統(tǒng)設(shè)計方案和產(chǎn)品迭代計劃捌臊。
最終豁鲤，和公司整體發(fā)展相互協(xié)調(diào)，相輔相成惫恼。
