概述

本文主要講述了在傳統(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è)外部用戶(hù)使用的系統(tǒng)都在這一層，包括官網(wǎng)渡讼、普通用戶(hù)使用的C端骂束，還包括給商戶(hù)使用的商家后臺(tái)和在各個(gè)銷(xiāo)售渠道進(jìn)行分銷(xiāo)的系統(tǒng)，比如與銀行信用卡中心合作成箫、微信合作在合作商的平臺(tái)露出本企業(yè)的產(chǎn)品展箱。這類(lèi)系統(tǒng)站在與客戶(hù)接觸的最前線，是公司實(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)惠信息的促銷(xiāo)系統(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ù)效率。這類(lèi)系統(tǒng)主要給其他應(yīng)用系統(tǒng)提供基礎(chǔ)服務(wù)能力支持挤聘。

3. 訂單系統(tǒng)上下游關(guān)系

圖片

由此可見(jiàn)轰枝，訂單系統(tǒng)對(duì)上接收用戶(hù)信息，將用戶(hù)信息轉(zhuǎn)化為產(chǎn)品訂單组去，同時(shí)管理并跟蹤訂單信息和數(shù)據(jù)狸膏，承載了公司整個(gè)交易線的重要對(duì)客環(huán)節(jié)。對(duì)下則銜接產(chǎn)品系統(tǒng)添怔、促銷(xiāo)系統(tǒng)湾戳、倉(cāng)儲(chǔ)系統(tǒng)、會(huì)員系統(tǒng)广料、支付系統(tǒng)等砾脑，對(duì)整個(gè)電商平臺(tái)起著承上啟下的作用。

4. 訂單系統(tǒng)的業(yè)務(wù)架構(gòu)

圖片

（1）訂單服務(wù)該模塊的主要功能是用戶(hù)日常使用的服務(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ō)莹汤。（架構(gòu)之家公眾號(hào)：itfly8）（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)惠痢艺、用戶(hù)仓洼、支付信息等一系列的訂單實(shí)時(shí)數(shù)據(jù)，來(lái)和下游系統(tǒng)堤舒，如：促銷(xiāo)色建、倉(cāng)儲(chǔ)、物流進(jìn)行交互舌缤。以一個(gè)通用B2C商城的訂單為例箕戳，梳理其包含的信息如下：這里要注意的是訂單類(lèi)型，隨著平臺(tái)業(yè)務(wù)的不斷發(fā)展国撵，品類(lèi)豐富陵吸、交易方式豐富后，需要對(duì)訂單進(jìn)行多維度的分類(lèi)管理介牙，同時(shí)訂單類(lèi)型利于訂單系統(tǒng)的擴(kuò)展性壮虫。每種訂單類(lèi)型將會(huì)對(duì)應(yīng)一套流程及一套狀態(tài)，便于對(duì)訂單進(jìn)行分類(lèi)管理和復(fù)用耻瑟。

2. 流程引擎

圖片

訂單創(chuàng)建：用戶(hù)下單后，系統(tǒng)需要生成訂單炊汹，此時(shí)需要先獲取下單中涉及的商品信息躬充，然后獲取該商品所涉及到的優(yōu)惠信息，如果商品不參與優(yōu)惠信息，則無(wú)此環(huán)節(jié)充甚。接著獲取該賬戶(hù)的會(huì)員權(quán)益以政，這里要注意的是：優(yōu)惠信息與會(huì)員權(quán)益的區(qū)別，比如：商品滿(mǎn)減是優(yōu)惠信息津坑，SUPER會(huì)員全場(chǎng)9.8折指的是會(huì)員權(quán)益妙蔗，一個(gè)是針對(duì)商品，另一個(gè)是針對(duì)賬戶(hù)疆瑰。其次就是優(yōu)惠活動(dòng)的疊加規(guī)則和優(yōu)先級(jí)規(guī)則等。增減庫(kù)存規(guī)則是指訂單中的商品昙啄，何時(shí)從倉(cāng)儲(chǔ)系統(tǒng)中對(duì)相應(yīng)商品庫(kù)存進(jìn)行扣除穆役，目前主流有兩種方式：下單減庫(kù)存——即用戶(hù)下單成功時(shí)減少庫(kù)存數(shù)量

• 優(yōu)勢(shì)：用戶(hù)體驗(yàn)友好，系統(tǒng)邏輯簡(jiǎn)潔梳凛；
• 缺點(diǎn)：會(huì)導(dǎo)致惡意下單或下單后卻不買(mǎi)耿币，使得真正有需求的用戶(hù)無(wú)法購(gòu)買(mǎi)，影響真實(shí)銷(xiāo)量韧拒；

解決辦法：

1. 設(shè)置訂單有效時(shí)間淹接，若訂單創(chuàng)建成功N分鐘不付款，則訂單取消叛溢，庫(kù)存回滾塑悼；
2. 限購(gòu)，用各種條件來(lái)限制買(mǎi)家的購(gòu)買(mǎi)件數(shù)楷掉，比如一個(gè)賬號(hào)厢蒜、一個(gè)ip，只能買(mǎi)一件烹植；
3. 風(fēng)控斑鸦，從技術(shù)角度進(jìn)行判斷，屏蔽惡意賬號(hào)草雕，禁止惡意賬號(hào)購(gòu)買(mǎi)巷屿。

付款減庫(kù)存——即用戶(hù)支付完成并反饋給平臺(tái)后再減少庫(kù)存數(shù)量

• 優(yōu)勢(shì)：減少無(wú)效訂單帶來(lái)的資源損耗；
• 缺點(diǎn)：因第三方支付返回結(jié)果存在時(shí)差墩虹，同一時(shí)間多個(gè)用戶(hù)同時(shí)付款成功嘱巾，會(huì)導(dǎo)致下單數(shù)目超過(guò)庫(kù)存，商家?guī)齑娌蛔闳菀滓l(fā)斷貨和投訴败晴，成本增加浓冒。

解決辦法：

1. 付款前再次校驗(yàn)庫(kù)存，如確認(rèn)訂單要付款時(shí)再驗(yàn)證一次尖坤，并友好提示用戶(hù)庫(kù)存不足稳懒；
2. 增加提示信息：在商品詳情頁(yè)，訂單步驟頁(yè)面提示不及時(shí)付款，不能保證有庫(kù)存等场梆。

綜上所述墅冷，兩種方式各有優(yōu)缺點(diǎn)，因此或油，需結(jié)合實(shí)際場(chǎng)景進(jìn)行考慮寞忿，如：秒殺、搶購(gòu)顶岸、促銷(xiāo)活動(dòng)等腔彰，可使用下單減庫(kù)存的方式。而對(duì)于產(chǎn)品庫(kù)存量大辖佣，并發(fā)流量沒(méi)有那么強(qiáng)的產(chǎn)品使用付款減庫(kù)存的方式霹抛。將兩種方式帶入到銷(xiāo)售場(chǎng)景中，關(guān)聯(lián)商品類(lèi)型卷谈、促銷(xiāo)類(lèi)型杯拐、供需關(guān)系等，靈活使用世蔗，以充分發(fā)揮計(jì)算機(jī)系統(tǒng)的優(yōu)勢(shì)端逼。訂單支付：用戶(hù)支付完訂單后，需要獲取訂單的支付信息污淋，包括支付流水號(hào)顶滩、支付時(shí)間等。支付完訂單接著就是等商家發(fā)貨芙沥，但在發(fā)貨過(guò)程中诲祸，根據(jù)平臺(tái)業(yè)務(wù)模式的不同，可能會(huì)涉及到訂單的拆分而昨。訂單拆分一般分兩種：

• 一種是用戶(hù)挑選的商品來(lái)自于不同渠道（自營(yíng)與商家救氯，商家與商家）；
• 另一種是在SKU層面上拆分訂單：不同倉(cāng)庫(kù)歌憨，不同運(yùn)輸要求的SKU着憨，包裹重量體積限制等因素需要將訂單拆分。

image.gif

上面說(shuō)到逆向流程是各種修改訂單腕窥、取消訂單、退款筛婉、退貨等操作，需要梳理清楚這些流程與正向流程的關(guān)系癞松，才能理清訂單系統(tǒng)完整的訂單流程爽撒。訂單修改：可梳理訂單內(nèi)信息，根據(jù)信息關(guān)聯(lián)程度及業(yè)務(wù)訴求响蓉，設(shè)定訂單的可修改范圍是什么硕勿，比如：客戶(hù)下單后，想修改收貨人地址及電話枫甲。此時(shí)只需對(duì)相應(yīng)數(shù)據(jù)進(jìn)行更新即可源武。訂單取消：用戶(hù)提交訂單后沒(méi)有進(jìn)行支付操作，此時(shí)用戶(hù)原則上屬于取消訂單想幻，因?yàn)檫€未付款粱栖，則比較簡(jiǎn)單，只需要將原本提交訂單時(shí)扣減的庫(kù)存補(bǔ)回脏毯，促銷(xiāo)優(yōu)惠中使用的優(yōu)惠券闹究，權(quán)益等視平臺(tái)規(guī)則，進(jìn)行相應(yīng)補(bǔ)回食店。退款：用戶(hù)支付成功后渣淤，客戶(hù)發(fā)出退款的訴求后，需商戶(hù)進(jìn)行退款審核吉嫩，雙方達(dá)成一致后价认，系統(tǒng)應(yīng)以退款單的形式完成退款，關(guān)聯(lián)原訂單數(shù)據(jù)自娩。因商品無(wú)變化用踩，所以不需考慮與庫(kù)存系統(tǒng)的交互，僅需考慮促銷(xiāo)系統(tǒng)及支付系統(tǒng)交互即可。退貨：用戶(hù)支付成功后捶箱，客戶(hù)發(fā)出退貨的訴求后智什，需商戶(hù)進(jìn)行退款審核，雙方達(dá)成一致后丁屎，需對(duì)庫(kù)存系統(tǒng)進(jìn)行補(bǔ)回荠锭，支付系統(tǒng)、促銷(xiāo)系統(tǒng)以退款單形式完成退款晨川。最后证九，在退款/退貨流程中，需結(jié)合平臺(tái)業(yè)務(wù)場(chǎng)景共虑，考慮優(yōu)惠分?jǐn)偟倪壿嬂⒘诎l(fā)生退款/退貨時(shí)，優(yōu)惠該如何退回的處理規(guī)則和流程妈拌。（架構(gòu)之家公眾號(hào)：itfly8）（3）狀態(tài)機(jī)狀態(tài)機(jī)是管理訂單狀態(tài)邏輯的工具拥坛。狀態(tài)機(jī)可歸納為3個(gè)要素，即現(xiàn)態(tài)尘分、動(dòng)作猜惋、次態(tài)。

1. 現(xiàn)態(tài)：是指當(dāng)前所處的狀態(tài)培愁。
2. 動(dòng)作：動(dòng)作執(zhí)行完畢后著摔，可以遷移到新的狀態(tài)，也可以仍舊保持原狀態(tài)定续。
3. 次態(tài)：動(dòng)作滿(mǎn)足后要遷往的新?tīng)顟B(tài)谍咆，“次態(tài)”是相對(duì)于“現(xiàn)態(tài)”而言的，“次態(tài)”一旦被激活私股，就轉(zhuǎn)變成新的“現(xiàn)態(tài)”了摹察。

image.gif

訂單系統(tǒng)為了高效的對(duì)訂單進(jìn)行跟蹤和管理港粱，會(huì)對(duì)訂單流程當(dāng)中的關(guān)鍵節(jié)點(diǎn)，抽象出訂單狀態(tài)旦签。而訂單狀態(tài)從不同用戶(hù)的角度可分為查坪，系統(tǒng)訂單狀態(tài)、商家訂單狀態(tài)宁炫、買(mǎ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)映射表，以不同的用戶(hù)角色對(duì)系統(tǒng)訂單狀態(tài)進(jìn)行重新劃分蕾羊，以滿(mǎn)足不同用戶(hù)的需求喧笔。除此以外，隨著電商平臺(tái)的不斷發(fā)展龟再，不同的業(yè)務(wù)類(lèi)型书闸，所對(duì)應(yīng)的訂單狀態(tài)都會(huì)有所區(qū)別。所以利凑，訂單系統(tǒng)中一般會(huì)儲(chǔ)存多套狀態(tài)機(jī)浆劲，以滿(mǎn)足不同的訂單類(lèi)型來(lái)使用。訂單系統(tǒng)的發(fā)展訂單系統(tǒng)的主體框架哀澈，和主要業(yè)務(wù)模塊已基本講完梳侨，那么隨著企業(yè)的發(fā)展，業(yè)務(wù)量和業(yè)務(wù)形式不斷變化日丹，企業(yè)有可能形成多個(gè)訂單系統(tǒng)并存以滿(mǎn)足不同的業(yè)務(wù)需要的情況。業(yè)務(wù)系統(tǒng)架構(gòu)如下：

圖片

這種狀況的出現(xiàn)蚯嫌，將會(huì)給平臺(tái)帶來(lái)非常大的發(fā)展瓶頸哲虾，如：三個(gè)訂單系統(tǒng)，每個(gè)訂單系統(tǒng)處理不同類(lèi)型的訂單择示，沒(méi)有統(tǒng)一的訂單銷(xiāo)量束凑、訂單狀態(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ù)拟烫、促銷(xiāo)工具该编、客戶(hù)分單等系統(tǒng)都需要對(duì)接一遍，公共業(yè)務(wù)處理邏輯不統(tǒng)一硕淑，一旦邏輯變更课竣，多個(gè)系的同一個(gè)接口都要修改一遍嘉赎，接口的重復(fù)維護(hù)開(kāi)發(fā)工作量大。訂單開(kāi)發(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ù)鬓长。最后對(duì)于企業(yè)訂單系統(tǒng)的搭建谒拴，并不是要做的大而全、也不是要小而精涉波。而需要結(jié)合市場(chǎng)英上、公司、業(yè)務(wù)的實(shí)際情況來(lái)最終制定系統(tǒng)設(shè)計(jì)方案和產(chǎn)品迭代計(jì)劃啤覆。最終苍日，和公司整體發(fā)展相互協(xié)調(diào)，相輔相成窗声。