交易系统是电商行业非常重要的部分，那么，如何做一个交易结算系统呢？本篇文章将系统地介绍设计结算系统的方法及思路，能给产品设计的伙伴们提供一些设计思考和建议。
本文主要探讨的是电商行业交易结算系统的设计思路，希望借此内容同大家进行交流。
开始进入正题前我们必须要了解【交易】的几类定义。
说完几类交易的定义我们回到本文的主角电商交易，广义的电商交易包含了正向和逆向两条核心的链路流程：
广义电商交易所涉及的领域宽度非常之广，几乎涵盖了电商业务的所有核心系统。
但本次我们要涉及的是狭义的电商交易（指购物车和结算），本文主要介绍电商交易-结算（下面统称“交易结算”）。
借用一句广告语“我们（交易结算系统）不生产数据，只是数据的搬运工”。
为什么这样说？
我们可以从两个层面来阐述下交易结算的系统职责：
在此过程中交易结算扮演着将上游产生的数据搬运和传递至下游，并对数据进行校验、整合处理，过程中并未生产出新的数据。
移动端结算页：
PC端结算页：
从以上主流平台的交易结算页我们可以观察的，结算页核心的信息主要包含了【商品信息】、【配送信息】、【金额信息】（可查看下图）。
这些信息的呈现并非孤立的展示，背后有一套严谨的流程和校验在支持着，这便是本文所述的【交易结算系统】。
有了对电商交易结算和结算系统的基本认知，下文我们将剖析的说明如何建设我们的交易结算系统。
从这里开始，我们将一步一步的探讨建设交易结算系统的方法。
目前市面上的交易结算五花八门，有传统的标品交易、本地服务交易、知识付费交易、跨境电商交易等等，不同的交易在本质上无明显差异但在实现和设计中是会存在业务性质差异的。
这里我们主要以标准商品为交易对象进行模拟交易结算系统的建设。
首先识别我们需要建设的交易结算服务的业务形态，主要从以人货场三个核心要素进行有效识别：
通过对核心要素（人货场）的识别后，假设我们识别的三核心要素为：Toc交易（交易对象为个人）、实物商品和线上交易（APP）。
我们会对交易业务形态有个一个初步的认知：商户将通过线上交易(App)将实物商品卖给个人用户。
在对交易形态有初步认知后，需要思考通过哪些业务场景可以进入到结算页，以满足用户需要结算的诉求。
理论上任何明确了核心三要素（人货场）的页面都可以进入到结算页，我们一般看到可以进入结算页主要入口包含但不限：购物车页面、商品详情页、商品活动页、订单详列表页、订单详情页、商品评价页。
进入结算页后同样需要思考和整理结算页我们需要支持哪些业务的操作场景。
如下图：
基于我们对交易形态的初步认知和对结算场景的识别，我们需要思考交易结算的核心要素人、货、场需要在本次结算中满足哪些必须的条件，才能确保交易结算页所展示数据的正确性和有效性。即本次结算的对买卖双方都是公平且有效的。
如何确保交易结算页数据的有效性和正确性：
通过对交易结算服务域和服务能力的抽象，接下来我们将践行“我们不生产数据，只是数据的搬运工”口号。
交易结算在整个处理过程中并非自己闭环处理掉了所有服务，而是通过借用和串联各基础服务系统提供的数据和能力来解决结算所必须依赖的条件。
在整个结算系统执行过程中本质上并没有自己生产出数据，所需的数据都来源于基础的服务系统，那我们如何准确的知道应该向谁来借用数据和服务呢？
那就需要我们对企业内部系统及分工有较好的了解（交易的产品不仅需要本领域的深度，更需要有多领域的宽度），以便我们能够将我们需要借用的数据和服务划分到对应的系统。
如下表示例所示：
结算系统需要串联多个系统领域才能确保结算业务的完成，这个串联过程并非无序和随性，我们需要考虑如何串联才能达到理想的效果，以确保结算业务有序、准确、高效的执行。
这就需要我们考虑结算业务中所涉及所有服务的执行必要性、优先级和依赖关系。
例如我们将【商品营促销信息服务】先于【商品信息服务】，这显然是不合理，商品的有效性都没确定的情况下直接去确定营促销活动这是没法确保活动的可用性的。
因此我们需要明确结算业务的依赖关系和顺序，以确保我们可以判断哪些系统服务是必要的，哪些系统服务是高优先级的，对其进行划分和简单排序。
如下图：
结算所依赖的系统服务必要性和优先级初步确认完成，到这步还不够，因为还是不能清晰的表达具体交互顺序和交互的核心内容到底是什么？
这就需要我们进一步梳理结算系统的工作流程图，这里可以用于梳理的工具和流程类型很多，我个人一般喜欢用时序图来表达。在梳理流程的过程中有几个点我们必须明确：
后续我们需要做的就是结合实际的结算业务形态进行系统的的串联，串联过程中我们需要根据依赖优先级确保串联的流程尽量的简单、高效，以尽量少的交互，确保结算高效、准确的完成工作。
通常情况我们会以【商家】>【用户】>【商品】>【库存】>【营促销】>【履约】>【计价】>【订单】这样的顺序来串联（可根据结算业务的特性调整顺序）。并明确每一步交互的内容，以及对内容的反馈和基本处理。
如下图，这里仅是示例各行各业需要根据自身结算业务来处理：
结算系统在一次交易过程中，承接了不同系统给到的交易数据，这些交易数据既要作为上下游串联的参数，又需要作为交易的结果数据提供给前端进行处理和展示。所以对于结算数据，结算系统用什么样的模型去承载就至关重要。
由于结算系统几乎是不会使用到DB存储数据（考虑实时性和安全性），但数据需要提供给业务展示及订单系统落库。因此需要结合业务层展示的要求和订单系统落库数据的要求去设计结算系统的模型。
通过以上两者的诉求，可将结算系统的数据模型一般抽象为三个层级【结算维度】、【订单维度】和【商品维度】每个维度可根据实际的业务形态承载不同的信息。
可参下图：
交易结算上承业务，下串系统，通过对结算业务的识别、抽象，可将结算系统按照业务的需求及未来业务的发展需要进行抽象、规整对应的功能域（例如：商品域、CRM域、商品域、库存域、促销域…）。
每个功能域内可再进行能力的细分，确保每个能力的独立性和可复用性，以便于支持业务的快速迭代和创新。
当结算域所需能力规划和整理清楚后，结算另一个重要的职责则是根据实际的业务需要选择对应的能力域及域内能力进行合理、高效的有序编排和串联，为业务提供所需的结算流程服务。
结算这种基于业务诉求进行编排和串联的能力，就完全依赖我们对结算能力域的划分及能力域细分能力的抽象。
这里并不需要我们一次完成所有的能力域和细分能力的建设，但需要考虑每一个能力域的定位、职责，以及细分能力提供的服务的完整性和可拓展性。
结算编排的流程承接相应的结算业务，结算提供的流程应用结算域及能力进行编排串联，因为结算并不生产数据，结算能力域所提供的各种能力服务需要依赖下游系统提供服务。
所以结算系统在整个交易过程中承担着是“串联”和“编排”的责任。
综上内容我们可以大致的勾画出我们的交易结算产品模型（如下图），以便于大家理解和记忆：
本人对交易结算系统的产品设计思路和方法基本介绍完了，文章仅对结算系统的核心内容做了简略的概括说明，并没有将结算系统中所有处理细节和逻辑进行阐述。因为不同的业态、企业对结算都有自己认知和理解，细节的掌控需要结合实际业务。
现在的结算业务玩法千千万，但都基本脱离不开本文中所提到的核心要点，希望此文能对各位同仁有借鉴意义，谢谢。
最后说句废话：产品没有标准答案，用户喜欢的才是最好的。
本文由 @淡淡优雅 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。