产品如何设计交易系统——结算篇（0-1）

交易系统是电商行业非常重要的部分，那么，如何做一个交易结算系统呢？本篇文章将系统地介绍设计结算系统的方法及思路，能给产品设计的伙伴们提供一些设计思考和建议。

一、交易结算系统定义说明

本文主要探讨的是电商行业交易结算系统的设计思路，希望借此内容同大家进行交流。

开始进入正题前我们必须要了解【交易】的几类定义。

交易：指双方以货币及服务为媒介的价值交换。
电子交易：指应用信息技术来传递商务信息和交易。
电商交易：指双方应用线上平台或工具进行的等价值交换（作者理解）。

说完几类交易的定义我们回到本文的主角电商交易，广义的电商交易包含了正向和逆向两条核心的链路流程：

正向以订单单据为主，驱动正向交易的全生命流程（创建-支付-发货-收货-评价-财务…）。
逆向以售后单为主，驱动逆向交易的全生命流程（创建-审核-退货-收货-退款-财务…）。

广义电商交易所涉及的领域宽度非常之广，几乎涵盖了电商业务的所有核心系统。

但本次我们要涉及的是狭义的电商交易（指购物车和结算），本文主要介绍电商交易-结算（下面统称“交易结算”）。

二、交易结算系统职责

借用一句广告语“我们（交易结算系统）不生产数据，只是数据的搬运工”。

为什么这样说？

我们可以从两个层面来阐述下交易结算的系统职责：

业务层面。交易结算主要职责将确定的商品、买卖方和金额等信息以匹配的业务结算流程进行校验、处理、整合，以确保交易的有效性和准确性，以促进交易高效、快速、安全的完成。交易环节中核心业务对象（人、货、场）都非交易结算产物，交易结算仅对它们进行了辨识和整合。
系统层面。交易结算主要职责为有序的串联本次交易所涉及的所有关联系统及服务，将参与交易的系统领域（商户、会员、商品、库存、营促销、支付等），进行有序的处理、校验和整合，以确保本次交易时刻的数据在所有系统域内是准确且有效的。

在此过程中交易结算扮演着将上游产生的数据搬运和传递至下游，并对数据进行校验、整合处理，过程中并未生产出新的数据。

三、常见的交易结算

移动端结算页：

PC端结算页：

从以上主流平台的交易结算页我们可以观察的，结算页核心的信息主要包含了【商品信息】、【配送信息】、【金额信息】（可查看下图）。

这些信息的呈现并非孤立的展示，背后有一套严谨的流程和校验在支持着，这便是本文所述的【交易结算系统】。

有了对电商交易结算和结算系统的基本认知，下文我们将剖析的说明如何建设我们的交易结算系统。

四、交易结算系统的设计方法

从这里开始，我们将一步一步的探讨建设交易结算系统的方法。

目前市面上的交易结算五花八门，有传统的标品交易、本地服务交易、知识付费交易、跨境电商交易等等，不同的交易在本质上无明显差异但在实现和设计中是会存在业务性质差异的。

这里我们主要以标准商品为交易对象进行模拟交易结算系统的建设。

1. 识别结算业务形态及场景

首先识别我们需要建设的交易结算服务的业务形态，主要从以人货场三个核心要素进行有效识别：

交易对象：卖家（个人/企业）、买家（个人/政企）。
交易商品：实物商品 / 虚拟商品 / 境外商品 / 服务商品…
交易场：线上交易 / 线下交易。

通过对核心要素（人货场）的识别后，假设我们识别的三核心要素为：Toc交易（交易对象为个人）、实物商品和线上交易（APP）。

我们会对交易业务形态有个一个初步的认知：商户将通过线上交易(App)将实物商品卖给个人用户。

在对交易形态有初步认知后，需要思考通过哪些业务场景可以进入到结算页，以满足用户需要结算的诉求。

理论上任何明确了核心三要素（人货场）的页面都可以进入到结算页，我们一般看到可以进入结算页主要入口包含但不限：购物车页面、商品详情页、商品活动页、订单详列表页、订单详情页、商品评价页。

进入结算页后同样需要思考和整理结算页我们需要支持哪些业务的操作场景。

如下图：

2. 抽象结算所需服务能力

基于我们对交易形态的初步认知和对结算场景的识别，我们需要思考交易结算的核心要素人、货、场需要在本次结算中满足哪些必须的条件，才能确保交易结算页所展示数据的正确性和有效性。即本次结算的对买卖双方都是公平且有效的。

如何确保交易结算页数据的有效性和正确性：

我们需要针对我们交易的核心要素（人、货、场）进行疑问式思考（如下表/交易结算核心考虑问题）。
接着对我们提出的服务进行抽象分类（如下表/抽象服务域）。
再对我们的抽象服务所需要提供的服务进行拆分和抽象（如下表/服务能力抽象）。
最后必须确保我们所抽象出的服务能力有对应的承接方给出明确解决方案和结果。

3. 划分结算服务至对应系统

通过对交易结算服务域和服务能力的抽象，接下来我们将践行“我们不生产数据，只是数据的搬运工”口号。

交易结算在整个处理过程中并非自己闭环处理掉了所有服务，而是通过借用和串联各基础服务系统提供的数据和能力来解决结算所必须依赖的条件。

在整个结算系统执行过程中本质上并没有自己生产出数据，所需的数据都来源于基础的服务系统，那我们如何准确的知道应该向谁来借用数据和服务呢？

那就需要我们对企业内部系统及分工有较好的了解（交易的产品不仅需要本领域的深度，更需要有多领域的宽度），以便我们能够将我们需要借用的数据和服务划分到对应的系统。

如下表示例所示：

4. 梳理结算上下游依赖顺序

结算系统需要串联多个系统领域才能确保结算业务的完成，这个串联过程并非无序和随性，我们需要考虑如何串联才能达到理想的效果，以确保结算业务有序、准确、高效的执行。

这就需要我们考虑结算业务中所涉及所有服务的执行必要性、优先级和依赖关系。

例如我们将【商品营促销信息服务】先于【商品信息服务】，这显然是不合理，商品的有效性都没确定的情况下直接去确定营促销活动这是没法确保活动的可用性的。

因此我们需要明确结算业务的依赖关系和顺序，以确保我们可以判断哪些系统服务是必要的，哪些系统服务是高优先级的，对其进行划分和简单排序。

如下图：

5. 梳理结算系统交互时序图

结算所依赖的系统服务必要性和优先级初步确认完成，到这步还不够，因为还是不能清晰的表达具体交互顺序和交互的核心内容到底是什么？

这就需要我们进一步梳理结算系统的工作流程图，这里可以用于梳理的工具和流程类型很多，我个人一般喜欢用时序图来表达。在梳理流程的过程中有几个点我们必须明确：

明确参与交互的系统（通过“识别结算业务形态及场景”&“抽象结算所需服务能力”&“划分结算服务至对应系统”已明确）。
明确参与交互系统的工作职责（通过“划分结算服务至对应系统”已明确）。
明确参与交互系统所承担职责是否必要条件，以确定异常时是否终止结算（通过“梳理结算上下游依赖顺序”已明确）。

后续我们需要做的就是结合实际的结算业务形态进行系统的的串联，串联过程中我们需要根据依赖优先级确保串联的流程尽量的简单、高效，以尽量少的交互，确保结算高效、准确的完成工作。

通常情况我们会以【商家】>【用户】>【商品】>【库存】>【营促销】>【履约】>【计价】>【订单】这样的顺序来串联（可根据结算业务的特性调整顺序）。并明确每一步交互的内容，以及对内容的反馈和基本处理。

如下图，这里仅是示例各行各业需要根据自身结算业务来处理：

6. 确定结算数据承载模型

结算系统在一次交易过程中，承接了不同系统给到的交易数据，这些交易数据既要作为上下游串联的参数，又需要作为交易的结果数据提供给前端进行处理和展示。所以对于结算数据，结算系统用什么样的模型去承载就至关重要。

由于结算系统几乎是不会使用到DB存储数据（考虑实时性和安全性），但数据需要提供给业务展示及订单系统落库。因此需要结合业务层展示的要求和订单系统落库数据的要求去设计结算系统的模型。

业务层：一般会分【结算维度】数据和【商品维度】数据展示给到用户，以便用户能够快速、清晰的确认自己购买的商品（商品维度）、单价价格（商品维度）、活动（商品维度）、数量（商品维度）、配送信息（结算维度）、金额信息（结算维度（销售总金额、优惠总金额、应付总金额、实付总金额……）），以促使快速、安全的完成交易。
订单系统：为了后续订单数据使用及管理的规范性，一般会要求落单的数据区分为【订单维度】、【商品维度】、【活动信息】、【买家信息】、【卖家信息】…

通过以上两者的诉求，可将结算系统的数据模型一般抽象为三个层级【结算维度】、【订单维度】和【商品维度】每个维度可根据实际的业务形态承载不同的信息。

可参下图：