聊聊訂單系統(tǒng)的設(shè)計(jì)?
時(shí)間:2023-12-29
點(diǎn)擊:66次
本文主要講述了在傳統(tǒng)電商企業(yè)中,訂單系統(tǒng)應(yīng)承載的角色,就訂單系統(tǒng)所包含的主要功能模塊梳理了設(shè)計(jì)思路,并對(duì)訂單系統(tǒng)未來(lái)的發(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é)與功能,進(jìn)而保證各系統(tǒng)之間高效簡(jiǎn)潔的工作。
2. 訂單系統(tǒng)與各業(yè)務(wù)系統(tǒng)的關(guān)系
(1)對(duì)外系統(tǒng):
所有給企業(yè)外部用戶使用的系統(tǒng)都在這一層,包括官網(wǎng)、普通用戶使用的c端,還包括給商戶使用的商家后臺(tái)和在各個(gè)銷售渠道進(jìn)行分銷的系統(tǒng),比如與銀行信用卡中心合作、微信合作在合作商的平臺(tái)露出本企業(yè)的產(chǎn)品。這類系統(tǒng)站在與客戶接觸的最前線,是公司實(shí)現(xiàn)商業(yè)模式的橋頭堡。
(2)管理中后臺(tái):
每個(gè)c端的業(yè)務(wù)形態(tài)都會(huì)有一個(gè)對(duì)應(yīng)的系統(tǒng)模塊,如負(fù)責(zé)管理平臺(tái)交易的訂單系統(tǒng),管理優(yōu)惠信息的促銷系統(tǒng),管理平臺(tái)所有產(chǎn)品的產(chǎn)品系統(tǒng),以及管理所有對(duì)外系統(tǒng)顯示內(nèi)容的內(nèi)容系統(tǒng)等。
(3)公共服務(wù)系統(tǒng):
隨著企業(yè)的發(fā)展,信息化建設(shè)到達(dá)一定程度后,企業(yè)需要將通用功能服務(wù)化、平臺(tái)化,以保證應(yīng)用架構(gòu)的合理性,提升服務(wù)效率。這類系統(tǒng)主要給其他應(yīng)用系統(tǒng)提供基礎(chǔ)服務(wù)能力支持。
3. 訂單系統(tǒng)上下游關(guān)系
由此可見(jiàn),訂單系統(tǒng)對(duì)上接收用戶信息,將用戶信息轉(zhuǎn)化為產(chǎn)品訂單,同時(shí)管理并跟蹤訂單信息和數(shù)據(jù),承載了公司整個(gè)交易線的重要對(duì)客環(huán)節(jié)。對(duì)下則銜接產(chǎn)品系統(tǒng)、促銷系統(tǒng)、倉(cāng)儲(chǔ)系統(tǒng)、會(huì)員系統(tǒng)、支付系統(tǒng)等,對(duì)整個(gè)電商平臺(tái)起著承上啟下的作用。
5. 訂單系統(tǒng)的業(yè)務(wù)架構(gòu)
(1)訂單服務(wù)
該模塊的主要功能是用戶日常使用的服務(wù)和頁(yè)面,主要有訂單列表、訂單詳情、在線下單等,還包括為公共業(yè)務(wù)模塊提供的多維度訂單數(shù)據(jù)服務(wù)。
(2)訂單邏輯
訂單系統(tǒng)的核心,起著至關(guān)重要的作用,在訂單系統(tǒng)負(fù)責(zé)管理訂單創(chuàng)建、訂單支付、訂單生產(chǎn)、訂單確認(rèn)、訂單完成、取消訂單等訂單流程。還涉及到復(fù)雜的訂單狀態(tài)規(guī)則、訂單金額計(jì)算規(guī)則以及增減庫(kù)存規(guī)則等。在4節(jié)核心功能設(shè)計(jì)中會(huì)重點(diǎn)來(lái)說(shuō)。
(3)底層服務(wù)
信息化建設(shè)達(dá)到一定程度的企業(yè),一般會(huì)將公司公共服務(wù)模塊化,比如:產(chǎn)品,會(huì)構(gòu)建對(duì)應(yīng)的產(chǎn)品系統(tǒng),代碼、數(shù)據(jù)庫(kù),接口等相對(duì)獨(dú)立。但是,這也帶來(lái)了一個(gè)問(wèn)題,比如:訂單創(chuàng)建的場(chǎng)景下需要獲取的信息分散在各個(gè)系統(tǒng)。
如果需要從各個(gè)公共服務(wù)系統(tǒng)調(diào)用:一是會(huì)花費(fèi)大量時(shí)間,二是代碼的維護(hù)成本非常高。因此,訂單系統(tǒng)接入所需的公共服務(wù)模塊接口,在訂單系統(tǒng)即可完成對(duì)接公共系統(tǒng)的服務(wù)。
訂單系統(tǒng)核心功能
1. 訂單中所包含的內(nèi)容信息
為了使訂單系統(tǒng)能夠?qū)τ唵芜M(jìn)行高效、精準(zhǔn)的管理和跟蹤,訂單會(huì)儲(chǔ)存關(guān)于產(chǎn)品、優(yōu)惠、用戶、支付信息等一系列的訂單實(shí)時(shí)數(shù)據(jù),來(lái)和下游系統(tǒng),如:促銷、倉(cāng)儲(chǔ)、物流進(jìn)行交互。
以一個(gè)通用b2c商城的訂單為例,梳理其包含的信息如下:
這里要注意的是訂單類型,隨著平臺(tái)業(yè)務(wù)的不斷發(fā)展,品類豐富、交易方式豐富后,需要對(duì)訂單進(jìn)行多維度的分類管理,同時(shí)訂單類型利于訂單系統(tǒng)的擴(kuò)展性。每種訂單類型將會(huì)對(duì)應(yīng)一套流程及一套狀態(tài),便于對(duì)訂單進(jìn)行分類管理和復(fù)用。
2. 流程引擎
流程是指從平臺(tái)角度出發(fā),將訂單從創(chuàng)建到完成的整個(gè)流轉(zhuǎn)過(guò)程進(jìn)行抽象,從而行程了一套標(biāo)準(zhǔn)流程規(guī)則。而不同的產(chǎn)品類型或交易類型在系統(tǒng)中的流程會(huì)千差萬(wàn)別,因此為了方便對(duì)訂單流程進(jìn)行管理,會(huì)組建流程引擎模塊。
每套訂單流程中會(huì)包含正向流程及逆向流程,正向流程可以比作一次順利的網(wǎng)購(gòu)體驗(yàn)過(guò)程中,后臺(tái)系統(tǒng)之間的信息流轉(zhuǎn)。逆向流程則是修改訂單、取消訂單、退款、退貨等各種動(dòng)作引起的后臺(tái)系統(tǒng)流程,同時(shí)每個(gè)流程觸發(fā)的條件又可分為系統(tǒng)觸發(fā)和人工觸發(fā)兩種場(chǎng)景。
(1)正向流程
以一個(gè)通用b2c商城的訂單系統(tǒng)為例,根據(jù)其實(shí)際業(yè)務(wù)場(chǎng)景,其訂單流程可抽象為5大步驟:訂單創(chuàng)建>訂單支付>訂單生產(chǎn)>訂單確認(rèn)>訂單完成。
而每個(gè)步驟的背后,訂單是如何在多系統(tǒng)之間交互流轉(zhuǎn)的,可概括如下圖:
訂單創(chuàng)建:
用戶下單后,系統(tǒng)需要生成訂單,此時(shí)需要先獲取下單中涉及的商品信息,然后獲取該商品所涉及到的優(yōu)惠信息,如果商品不參與優(yōu)惠信息,則無(wú)此環(huán)節(jié)。
接著獲取該賬戶的會(huì)員權(quán)益,這里要注意的是:優(yōu)惠信息與會(huì)員權(quán)益的區(qū)別,比如:商品滿減是優(yōu)惠信息,super會(huì)員全場(chǎng)9.8折指的是會(huì)員權(quán)益,一個(gè)是針對(duì)商品,另一個(gè)是針對(duì)賬戶。其次就是優(yōu)惠活動(dòng)的疊加規(guī)則和優(yōu)先級(jí)規(guī)則等。
增減庫(kù)存規(guī)則是指訂單中的商品,何時(shí)從倉(cāng)儲(chǔ)系統(tǒng)中對(duì)相應(yīng)商品庫(kù)存進(jìn)行扣除,目前主流有兩種方式:
下單減庫(kù)存——即用戶下單成功時(shí)減少庫(kù)存數(shù)量
優(yōu)勢(shì): 用戶體驗(yàn)友好,系統(tǒng)邏輯簡(jiǎn)潔;
缺點(diǎn): 會(huì)導(dǎo)致惡意下單或下單后卻不買,使得真正有需求的用戶無(wú)法購(gòu)買,影響真實(shí)銷量;
解決辦法:
設(shè)置訂單有效時(shí)間,若訂單創(chuàng)建成功n分鐘不付款,則訂單取消,庫(kù)存回滾;
限購(gòu),用各種條件來(lái)限制買家的購(gòu)買件數(shù),比如一個(gè)賬號(hào)、一個(gè)ip,只能買一件;
風(fēng)控,從技術(shù)角度進(jìn)行判斷,屏蔽惡意賬號(hào),禁止惡意賬號(hào)購(gòu)買。
付款減庫(kù)存——即用戶支付完成并反饋給平臺(tái)后再減少庫(kù)存數(shù)量
優(yōu)勢(shì): 減少無(wú)效訂單帶來(lái)的資源損耗;
缺點(diǎn): 因第三方支付返回結(jié)果存在時(shí)差,同一時(shí)間多個(gè)用戶同時(shí)付款成功,會(huì)導(dǎo)致下單數(shù)目超過(guò)庫(kù)存,商家?guī)齑娌蛔闳菀滓l(fā)斷貨和投訴,成本增加。
解決辦法:
付款前再次校驗(yàn)庫(kù)存,如確認(rèn)訂單要付款時(shí)再驗(yàn)證一次,并友好提示用戶庫(kù)存不足;
增加提示信息:在商品詳情頁(yè),訂單步驟頁(yè)面提示不及時(shí)付款,不能保證有庫(kù)存等。
綜上所述,兩種方式各有優(yōu)缺點(diǎn),因此,需結(jié)合實(shí)際場(chǎng)景進(jìn)行考慮,如:秒殺、搶購(gòu)、促銷活動(dòng)等,可使用下單減庫(kù)存的方式。而對(duì)于產(chǎn)品庫(kù)存量大,并發(fā)流量沒(méi)有那么強(qiáng)的產(chǎn)品使用付款減庫(kù)存的方式。
將兩種方式帶入到銷售場(chǎng)景中,關(guān)聯(lián)商品類型、促銷類型、供需關(guān)系等,靈活使用,以充分發(fā)揮計(jì)算機(jī)系統(tǒng)的優(yōu)勢(shì)。
訂單支付:
用戶支付完訂單后,需要獲取訂單的支付信息,包括支付流水號(hào)、支付時(shí)間等。支付完訂單接著就是等商家發(fā)貨,但在發(fā)貨過(guò)程中,根據(jù)平臺(tái)業(yè)務(wù)模式的不同,可能會(huì)涉及到訂單的拆分。
訂單拆分一般分兩種:
一種是用戶挑選的商品來(lái)自于不同渠道(自營(yíng)與商家,商家與商家);
另一種是在sku層面上拆分訂單:不同倉(cāng)庫(kù),不同運(yùn)輸要求的sku,包裹重量體積限制等因素需要將訂單拆分。
訂單拆分也是一個(gè)相對(duì)獨(dú)立的模塊,這里就不詳細(xì)描述了。
訂單生產(chǎn): 訂單生產(chǎn),是指產(chǎn)品從企業(yè)到用戶這一流程的概述。如電商平臺(tái)中,商家發(fā)貨過(guò)程已有一個(gè)標(biāo)準(zhǔn)化的流程,訂單內(nèi)容會(huì)發(fā)送到倉(cāng)庫(kù),倉(cāng)庫(kù)對(duì)商品進(jìn)行打單、揀貨、包裝、交接快遞進(jìn)行配送。
訂單確認(rèn): 收到貨后,訂單系統(tǒng)需要在快遞被簽收后提醒用戶對(duì)商品做評(píng)價(jià)。這里要注意,確認(rèn)收到貨不代表交易成功,相反是售后服務(wù)的開始。
訂單完成: 訂單完成是指在收到貨x天的狀態(tài),此時(shí)訂單不在售后的支持時(shí)間范圍內(nèi)。到此,一個(gè)訂單的正向流程就算走完了。
(2)逆向流程
上面說(shuō)到逆向流程是各種修改訂單、取消訂單、退款、退貨等操作,需要梳理清楚這些流程與正向流程的關(guān)系,才能理清訂單系統(tǒng)完整的訂單流程。
訂單修改: 可梳理訂單內(nèi)信息,根據(jù)信息關(guān)聯(lián)程度及業(yè)務(wù)訴求,設(shè)定訂單的可修改范圍是什么,比如:客戶下單后,想修改收貨人地址及電話。此時(shí)只需對(duì)相應(yīng)數(shù)據(jù)進(jìn)行更新即可。
訂單取消: 用戶提交訂單后沒(méi)有進(jìn)行支付操作,此時(shí)用戶原則上屬于取消訂單,因?yàn)檫€未付款,則比較簡(jiǎn)單,只需要將原本提交訂單時(shí)扣減的庫(kù)存補(bǔ)回,促銷優(yōu)惠中使用的優(yōu)惠券,權(quán)益等視平臺(tái)規(guī)則,進(jìn)行相應(yīng)補(bǔ)回。
退款: 用戶支付成功后,客戶發(fā)出退款的訴求后,需商戶進(jìn)行退款審核,雙方達(dá)成一致后,系統(tǒng)應(yīng)以退款單的形式完成退款,關(guān)聯(lián)原訂單數(shù)據(jù)。因商品無(wú)變化,所以不許考慮與庫(kù)存系統(tǒng)的交互,僅需考慮促銷系統(tǒng)及支付系統(tǒng)交互即可。
退貨: 用戶支付成功后,客戶發(fā)出退貨的訴求后,需商戶進(jìn)行退款審核,雙方達(dá)成一致后,需對(duì)庫(kù)存系統(tǒng)進(jìn)行補(bǔ)回,支付系統(tǒng)、促銷系統(tǒng)以退款單形式完成退款。最后,在退款/退貨流程中,需結(jié)合平臺(tái)業(yè)務(wù)場(chǎng)景,考慮優(yōu)惠分?jǐn)偟倪壿嫞诎l(fā)生退款/退貨時(shí),優(yōu)惠該如何退回的處理規(guī)則和流程。
(3)狀態(tài)機(jī)
狀態(tài)機(jī)是管理訂單狀態(tài)邏輯的工具。狀態(tài)機(jī)可歸納為3個(gè)要素,即現(xiàn)態(tài)、動(dòng)作、次態(tài)。
現(xiàn)態(tài): 是指當(dāng)前所處的狀態(tài)。
動(dòng)作: 動(dòng)作執(zhí)行完畢后,可以遷移到新的狀態(tài),也可以仍舊保持原狀態(tài)。
次態(tài): 動(dòng)作滿足后要遷往的新?tīng)顟B(tài),“次態(tài)”是相對(duì)于“現(xiàn)態(tài)”而言的,“次態(tài)”一旦被激活,就轉(zhuǎn)變成新的“現(xiàn)態(tài)”了。
狀態(tài)機(jī)的設(shè)計(jì)需要結(jié)合平臺(tái)實(shí)際業(yè)務(wù)場(chǎng)景,將狀態(tài)間的切換細(xì)化成了執(zhí)行了某個(gè)動(dòng)作。
以一個(gè)b2c商城的訂單系統(tǒng)舉例如下:
訂單系統(tǒng)為了高效的對(duì)訂單進(jìn)行跟蹤和管理,會(huì)對(duì)訂單流程當(dāng)中的關(guān)鍵節(jié)點(diǎn),抽象出訂單狀態(tài)。而訂單狀態(tài)從不同用戶的角度可分為,系統(tǒng)訂單狀態(tài)、商家訂單狀態(tài)、買家訂單狀態(tài)等。
對(duì)于訂單系統(tǒng)來(lái)說(shuō),訂單狀態(tài)細(xì)分的顆粒度越細(xì)、越明確,訂單系統(tǒng)管理的精度和可靠性就越高,比如:在待付款和待發(fā)貨兩個(gè)狀態(tài)中,訂單系統(tǒng)后臺(tái)會(huì)細(xì)分為訂單超時(shí)取消、訂單支付失敗、訂單付款完成等。
因此,訂單狀態(tài)模塊中,通常會(huì)維護(hù)狀態(tài)映射表,以不同的用戶角色對(duì)系統(tǒng)訂單狀態(tài)進(jìn)行重新劃分,以滿足不同用戶的需求。
除此以外,隨著電商平臺(tái)的不斷發(fā)展,不同的業(yè)務(wù)類型,所對(duì)應(yīng)的訂單狀態(tài)都會(huì)有所區(qū)別。所以,訂單系統(tǒng)中一般會(huì)儲(chǔ)存多套狀態(tài)機(jī),以滿足不同的訂單類型來(lái)使用。
訂單系統(tǒng)的發(fā)展
訂單系統(tǒng)的主體框架,和主要業(yè)務(wù)模塊已基本講完,那么隨著企業(yè)的發(fā)展,業(yè)務(wù)量和業(yè)務(wù)形式不斷變化,企業(yè)有可能形成多個(gè)訂單系統(tǒng)并存以滿足不同的業(yè)務(wù)需要的情況。
業(yè)務(wù)系統(tǒng)架構(gòu)如下:
這種狀況的出現(xiàn),將會(huì)給平臺(tái)帶來(lái)非常大的發(fā)展瓶頸,如:
三個(gè)訂單系統(tǒng),每個(gè)訂單系統(tǒng)處理不同類型的訂單,沒(méi)有統(tǒng)一的訂單銷量、訂單狀態(tài)信息,網(wǎng)站前臺(tái)對(duì)訂單的狀態(tài)展示與控制不統(tǒng)一,只能是在網(wǎng)站前臺(tái)會(huì)員中心硬代碼維護(hù)一套面向會(huì)員的統(tǒng)一訂單明細(xì)與狀態(tài)數(shù)據(jù)。而無(wú)線側(cè)上線后,由于不了解前臺(tái)網(wǎng)站會(huì)員中心的訂單狀態(tài)管理邏輯,所以需要把前臺(tái)網(wǎng)站的訂單明細(xì)及狀態(tài)管理再在無(wú)線應(yīng)用側(cè)再實(shí)現(xiàn)一遍。
三套后臺(tái)訂單系統(tǒng)與公共業(yè)務(wù)系統(tǒng)如會(huì)員中心、支付與財(cái)務(wù)、促銷工具、客戶分單等系統(tǒng)都需要對(duì)接一遍,公共業(yè)務(wù)處理邏輯不統(tǒng)一,一旦邏輯變更多個(gè)系統(tǒng)統(tǒng)一個(gè)接口都要修改一遍,接口的重復(fù)維護(hù)開發(fā)工作量大。
訂單開發(fā)目前分到事業(yè)部,各個(gè)事業(yè)部只會(huì)考慮自己的邏輯,不會(huì)考慮公共架構(gòu),只會(huì)越走越遠(yuǎn)。碰到像無(wú)線這樣的項(xiàng)目,需要對(duì)接各個(gè)事業(yè)部,無(wú)線側(cè)應(yīng)用上線進(jìn)展慢。
因此未來(lái)的訂單系統(tǒng)可拆分為訂單中心與業(yè)務(wù)訂單系統(tǒng)兩個(gè)模塊,以管理公司所有訂單數(shù)據(jù),并為各個(gè)模塊提供統(tǒng)一服務(wù)。
業(yè)務(wù)系統(tǒng)架構(gòu)如下:
最后
對(duì)于企業(yè)訂單系統(tǒng)的搭建,并不是要做的大而全、也不是要小而精。而需要結(jié)合市場(chǎng)、公司、業(yè)務(wù)的實(shí)際情況來(lái)最終制定系統(tǒng)設(shè)計(jì)方案和產(chǎn)品迭代計(jì)劃。
最終,和公司整體發(fā)展相互協(xié)調(diào),相輔相成。
本文來(lái)源于羅戈網(wǎng),不代表本站觀點(diǎn),如有侵權(quán)可聯(lián)系刪除,文章所用圖片來(lái)源于網(wǎng)絡(luò),文章圖片如有侵權(quán)可聯(lián)系刪除。