中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

交易系統是電商行業非常重要的部分，那么，如何做一個交易結算系統呢？本篇文章將系統地介紹設計結算系統的方法及思路，能給產品設計的伙伴們提供一些設計思考和建議。

一、交易結算系統定義說明

本文主要探討的是電商行業交易結算系統的設計思路，希望借此內容同大家進行交流。

開始進入正題前我們必須要了解【交易】的幾類定義。

• 交易：指雙方以貨幣及服務為媒介的價值交換。
• 電子交易：指應用信息技術來傳遞商務信息和交易。
• 電商交易：指雙方應用線上平臺或工具進行的等價值交換（作者理解）。

說完幾類交易的定義我們回到本文的主角電商交易，廣義的電商交易包含了正向和逆向兩條核心的鏈路流程：

1. 正向以訂單單據為主，驅動正向交易的全生命流程（創建-支付-發貨-收貨-評價-財務…）。
2. 逆向以售后單為主，驅動逆向交易的全生命流程（創建-審核-退貨-收貨-退款-財務…）。

廣義電商交易所涉及的領域寬度非常之廣，幾乎涵蓋了電商業務的所有核心系統。

但本次我們要涉及的是狹義的電商交易（指購物車和結算），本文主要介紹電商交易-結算（下面統稱“交易結算”）。

二、交易結算系統職責

借用一句廣告語“我們（交易結算系統）不生產數據，只是數據的搬運工”。

為什么這樣說？

我們可以從兩個層面來闡述下交易結算的系統職責：

1. 業務層面。交易結算主要職責將確定的商品、買賣方和金額等信息以匹配的業務結算流程進行校驗、處理、整合，以確保交易的有效性和準確性，以促進交易高效、快速、安全的完成。交易環節中核心業務對象（人、貨、場）都非交易結算產物，交易結算僅對它們進行了辨識和整合。
2. 系統層面。交易結算主要職責為有序的串聯本次交易所涉及的所有關聯系統及服務，將參與交易的系統領域（商戶、會員、商品、庫存、營促銷、支付等），進行有序的處理、校驗和整合，以確保本次交易時刻的數據在所有系統域內是準確且有效的。

在此過程中交易結算扮演著將上游產生的數據搬運和傳遞至下游，并對數據進行校驗、整合處理，過程中并未生產出新的數據。

三、常見的交易結算

移動端結算頁：

PC端結算頁：

從以上主流平臺的交易結算頁我們可以觀察的，結算頁核心的信息主要包含了【商品信息】、【配送信息】、【金額信息】（可查看下圖）。

這些信息的呈現并非孤立的展示，背后有一套嚴謹的流程和校驗在支持著，這便是本文所述的【交易結算系統】。

有了對電商交易結算和結算系統的基本認知，下文我們將剖析的說明如何建設我們的交易結算系統。

四、交易結算系統的設計方法

從這里開始，我們將一步一步的探討建設交易結算系統的方法。

目前市面上的交易結算五花八門，有傳統的標品交易、本地服務交易、知識付費交易、跨境電商交易等等，不同的交易在本質上無明顯差異但在實現和設計中是會存在業務性質差異的。

這里我們主要以標準商品為交易對象進行模擬交易結算系統的建設。

1. 識別結算業務形態及場景

首先識別我們需要建設的交易結算服務的業務形態，主要從以人貨場三個核心要素進行有效識別：

1. 交易對象：賣家（個人/企業）、買家（個人/政企）。
2. 交易商品：實物商品 / 虛擬商品 / 境外商品 / 服務商品…
3. 交易場：線上交易 / 線下交易。

通過對核心要素（人貨場）的識別后，假設我們識別的三核心要素為：Toc交易（交易對象為個人）、實物商品和線上交易（APP）。

我們會對交易業務形態有個一個初步的認知：商戶將通過線上交易(App)將實物商品賣給個人用戶。

在對交易形態有初步認知后，需要思考通過哪些業務場景可以進入到結算頁，以滿足用戶需要結算的訴求。

理論上任何明確了核心三要素（人貨場）的頁面都可以進入到結算頁，我們一般看到可以進入結算頁主要入口包含但不限：購物車頁面、商品詳情頁、商品活動頁、訂單詳列表頁、訂單詳情頁、商品評價頁。

進入結算頁后同樣需要思考和整理結算頁我們需要支持哪些業務的操作場景。

如下圖：

2. 抽象結算所需服務能力

基于我們對交易形態的初步認知和對結算場景的識別，我們需要思考交易結算的核心要素人、貨、場需要在本次結算中滿足哪些必須的條件，才能確保交易結算頁所展示數據的正確性和有效性。即本次結算的對買賣雙方都是公平且有效的。

如何確保交易結算頁數據的有效性和正確性：

1. 我們需要針對我們交易的核心要素（人、貨、場）進行疑問式思考（如下表/交易結算核心考慮問題）。
2. 接著對我們提出的服務進行抽象分類（如下表/抽象服務域）。
3. 再對我們的抽象服務所需要提供的服務進行拆分和抽象（如下表/服務能力抽象）。
4. 最后必須確保我們所抽象出的服務能力有對應的承接方給出明確解決方案和結果。

3. 劃分結算服務至對應系統

通過對交易結算服務域和服務能力的抽象，接下來我們將踐行“我們不生產數據，只是數據的搬運工”口號。

交易結算在整個處理過程中并非自己閉環處理掉了所有服務，而是通過借用和串聯各基礎服務系統提供的數據和能力來解決結算所必須依賴的條件。

在整個結算系統執行過程中本質上并沒有自己生產出數據，所需的數據都來源于基礎的服務系統，那我們如何準確的知道應該向誰來借用數據和服務呢？

那就需要我們對企業內部系統及分工有較好的了解（交易的產品不僅需要本領域的深度，更需要有多領域的寬度），以便我們能夠將我們需要借用的數據和服務劃分到對應的系統。

如下表示例所示：

4. 梳理結算上下游依賴順序

結算系統需要串聯多個系統領域才能確保結算業務的完成，這個串聯過程并非無序和隨性，我們需要考慮如何串聯才能達到理想的效果，以確保結算業務有序、準確、高效的執行。

這就需要我們考慮結算業務中所涉及所有服務的執行必要性、優先級和依賴關系。

例如我們將【商品營促銷信息服務】先于【商品信息服務】，這顯然是不合理，商品的有效性都沒確定的情況下直接去確定營促銷活動這是沒法確?；顒拥目捎眯缘?。

因此我們需要明確結算業務的依賴關系和順序，以確保我們可以判斷哪些系統服務是必要的，哪些系統服務是高優先級的，對其進行劃分和簡單排序。

如下圖：

5. 梳理結算系統交互時序圖

結算所依賴的系統服務必要性和優先級初步確認完成，到這步還不夠，因為還是不能清晰的表達具體交互順序和交互的核心內容到底是什么？

這就需要我們進一步梳理結算系統的工作流程圖，這里可以用于梳理的工具和流程類型很多，我個人一般喜歡用時序圖來表達。在梳理流程的過程中有幾個點我們必須明確：

1. 明確參與交互的系統（通過“識別結算業務形態及場景”&“抽象結算所需服務能力”&“劃分結算服務至對應系統”已明確）。
2. 明確參與交互系統的工作職責（通過“劃分結算服務至對應系統”已明確）。
3. 明確參與交互系統所承擔職責是否必要條件，以確定異常時是否終止結算（通過“梳理結算上下游依賴順序”已明確）。

后續我們需要做的就是結合實際的結算業務形態進行系統的的串聯，串聯過程中我們需要根據依賴優先級確保串聯的流程盡量的簡單、高效，以盡量少的交互，確保結算高效、準確的完成工作。

通常情況我們會以【商家】>【用戶】>【商品】>【庫存】>【營促銷】>【履約】>【計價】>【訂單】這樣的順序來串聯（可根據結算業務的特性調整順序）。并明確每一步交互的內容，以及對內容的反饋和基本處理。

如下圖，這里僅是示例各行各業需要根據自身結算業務來處理：

6. 確定結算數據承載模型

結算系統在一次交易過程中，承接了不同系統給到的交易數據，這些交易數據既要作為上下游串聯的參數，又需要作為交易的結果數據提供給前端進行處理和展示。所以對于結算數據，結算系統用什么樣的模型去承載就至關重要。

由于結算系統幾乎是不會使用到DB存儲數據（考慮實時性和安全性），但數據需要提供給業務展示及訂單系統落庫。因此需要結合業務層展示的要求和訂單系統落庫數據的要求去設計結算系統的模型。

• 業務層：一般會分【結算維度】數據和【商品維度】數據展示給到用戶，以便用戶能夠快速、清晰的確認自己購買的商品（商品維度）、單價價格（商品維度）、活動（商品維度）、數量（商品維度）、配送信息（結算維度）、金額信息（結算維度（銷售總金額、優惠總金額、應付總金額、實付總金額……）），以促使快速、安全的完成交易。
• 訂單系統：為了后續訂單數據使用及管理的規范性，一般會要求落單的數據區分為【訂單維度】、【商品維度】、【活動信息】、【買家信息】、【賣家信息】…

通過以上兩者的訴求，可將結算系統的數據模型一般抽象為三個層級【結算維度】、【訂單維度】和【商品維度】每個維度可根據實際的業務形態承載不同的信息。

可參下圖：

五、結算系統產品架構

交易結算上承業務，下串系統，通過對結算業務的識別、抽象，可將結算系統按照業務的需求及未來業務的發展需要進行抽象、規整對應的功能域（例如：商品域、CRM域、商品域、庫存域、促銷域…）。

每個功能域內可再進行能力的細分，確保每個能力的獨立性和可復用性，以便于支持業務的快速迭代和創新。

當結算域所需能力規劃和整理清楚后，結算另一個重要的職責則是根據實際的業務需要選擇對應的能力域及域內能力進行合理、高效的有序編排和串聯，為業務提供所需的結算流程服務。

結算這種基于業務訴求進行編排和串聯的能力，就完全依賴我們對結算能力域的劃分及能力域細分能力的抽象。

這里并不需要我們一次完成所有的能力域和細分能力的建設，但需要考慮每一個能力域的定位、職責，以及細分能力提供的服務的完整性和可拓展性。

結算編排的流程承接相應的結算業務，結算提供的流程應用結算域及能力進行編排串聯，因為結算并不生產數據，結算能力域所提供的各種能力服務需要依賴下游系統提供服務。

所以結算系統在整個交易過程中承擔著是“串聯”和“編排”的責任。

綜上內容我們可以大致的勾畫出我們的交易結算產品模型（如下圖），以便于大家理解和記憶：

六、說在最后

本人對交易結算系統的產品設計思路和方法基本介紹完了，文章僅對結算系統的核心內容做了簡略的概括說明，并沒有將結算系統中所有處理細節和邏輯進行闡述。因為不同的業態、企業對結算都有自己認知和理解，細節的掌控需要結合實際業務。

現在的結算業務玩法千千萬，但都基本脫離不開本文中所提到的核心要點，希望此文能對各位同仁有借鑒意義，謝謝。

最后說句廢話：產品沒有標準答案，用戶喜歡的才是最好的。