訂單系統(tǒng)設計思路_第1頁
訂單系統(tǒng)設計思路_第2頁
訂單系統(tǒng)設計思路_第3頁
訂單系統(tǒng)設計思路_第4頁
訂單系統(tǒng)設計思路_第5頁
已閱讀5頁,還剩3頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論