摘要
交易是业务流转的基础，其中交易系统和订单系统的设计至关重要。交易系统需确保安全、高效与稳定。在设计时，要考虑支付方式的多样性及兼容性，保障资金流转的准确与安全。同时，应具备良好的风险控制机制，防范欺诈等风险。订单系统则负责记录和管理交易的全过程。需清晰定义订单状态，如待支付、已支付、已发货等，以便用户和商家实时掌握交易进度。通过合理的数据库设计，确保订单数据的完整性和可查询性。此外，还应与物流系统等外部系统进行有效对接，实现业务的无缝流转。总之，精心设计的交易系统和订单系统能提升用户体验，保障业务的顺利进行，为企业的发展奠定坚实基础。
交易系统设计
就像电影台词里经常说的“今晚码头交易”；我要跟你做一个交易；交易被终止了；交易是一个司空见惯的词语，但是用在互联网产品领域，我们谈论的更多是一个狭义的交易概念，即交易系统，什么是交易、什么是交易系统、如何从宏观上把握交易系统框架以及从细节上完成交易系统的设计建模是本部分的重点。
交易模型
以家政O20平台为例，介绍交易核心所涉及到的内容，其中包含了家政的各类业务模型下的交易流程，以及不同模型中交易所涉及到的交易环节和这些环节的不同安排，以及交易中的交易各环节处理和账单部分。
现在很多家庭已经习惯了预约各种上门保洁服务，我们会先到家政类APP中挑选相关服务商品；对于平台来说这就是对用户的导购过程；挑选好合适的服务以后进行下单，这个过程要填写一些信息，比如多大房子、什么时候上门、家庭地址等信息，如果有优惠券还可以在下单时选择要使用的优惠券获得减免；订单填好号以后提交进入收银台进行支付，支付成功以后平台开始匹配阿姨，然后就是阿姨会按照约定时间上门服务；在服务即将结束时可以延长时间，最后结束后我们对阿姨的服务进行评价，或者对服务不满意进行投诉并申请部分退款。
交易业务框架
从上面的案例描述的交易全过程中，可以抽象出一个交易的业务框架，如图：
交易流程
从图4-1中可以看出，一次交易存在很多交易环节，而每一个交易环节都需要一些列的处理，并且这些交易环节是通过一定安排关联在一起的；所以交易过程需要与大量的相关服务进行交互，比如与营销系统联合处理卡券冻结与核销等，这样我们需要将平台交易抽象出众多交易环节，如图4-2所示：
这些交易环节并不是固定的，而是随着不同的交易模式而发生变化，因为一个平台会存在多种业务类型一不同的业务线、不同的城市、不同的经营模式等，从而形成了多样的交易模式，比如月嫂自营交易模式、月嫂经纪交易模式、保洁平台交易模式、保洁自营交易模式、保姆交易；还有其他因素比如单卖还是打包售卖、经纪业务还是对公业务、内部订单还是外部渠道订单等等。这样需要抽象出交易模式，哪些因素影响交易模式，这里我们从“业务线、售卖模式、经营模式、订单来源”四个维度定义交易模式，如图4-3所示：
所以因为业务的不同必然会造成某些交易环节的不同，比如月嫂交易不提供线上下单而是采用线上预约、线下面试、线上签单、线上支付的模式；而保洁交易可以在线上下单、支付等全链条进行操作，这样不同的交易模式就具备了不同的交易流程组合，从而完成整个交易模型的抽象，比如保洁普通交易模式的流程安排如如4-4，其他交易模式类似。
交易全链路
整个交易过程涉及到非常多的交易环节，每个交易环节针对不同的交易模式又存在不同的处理方式，而不同的交易处理需要与不同的业务系统进行交互，最终形成了以交易核心为中心的系统协同网络，如图4-5所示
整个交易过程中，每个环节都会有相应的交易安排，例如在对优惠券的交易处理过程中，用户在购物车或者订单填写页选择了相应优惠券，就需要对优惠券进行冻结处理，下单支付成功以后对优惠券进行核销。交易的复杂之处就是众多的交易环节以及交易处理流程；其中还包括逆向交易过程，比如用户取消了订单、支付成功后发起了退款、服务完成后发起了客诉、已经上报清算后发生了逆向。综上，设计好交易的关键一步就是对业务完成全局的抽象。
交易账单
账单是链接订单业务和资金处理业务也就是支付的枢纽，资金处理都是基于账单进行支付、付款、退款。一个订单可以创建多条账单，比如一个订单分2次支付则创建2个账单；一个账单又可以进行组合支付，比如三方支付+卡券+活动优惠；分别针对不同支付方式请求各系统完成支付处理；最后基于各渠道的支付结果推动清结算完成费用计算清分以及账务记录，这层关系如图4-6所示
上面提到，一个平台存在多种交易模式，在不同交易模式里就会存在不同的订单模式，而对于不同模式来说就需要不同类型的账单，比如ToC的账单和TB的账单会有区别，用户下单需要的账单和商家缴纳保证金的账单会有区别
一方面是不同的账单中包含的费用不同、账单金额的计算方法不同、账单的周期、操作等会存在差别。比如保洁存在预付账单和后付账单，而月嫂存在定金账单和尾款账单，保证金业务存在保证金账单，卡券售卖业务存在卡券售卖账单。设计好一个账单子系统也是整个交易非常重要的一环，账单模块如图4-7所示：
正向交易流程
用户正常的交易流程一般是这样的一用户选好了商品、添加购物车、填写订单、去支付、等待服务履约、完成，整个交易流程可以如图4-8所以：
- 用户购物车选好商品后去结算进行订单的填写
- 提交订单后完成订单的生成和账单的创建
- 交易核心请求支付核心获得收银台链接返回给用户端
- 用户完成支付
- 交易核心完成各类支付方式的支付结果处理并通知订单支付成功
- 交易核心基于支付结果通知清结算进行相关计费和记账
如果以4.1.2中的家政保洁交易案例为例，研究整个交易业务流程中详细的交互逻辑和细节，可以如图4-9所示：
交易订单的创建
用户提交订单以后，交易核心进行账单的创建，并且发起账单的支付处理，基于支付处理结果通知订单更新订单状态：假设本次保洁服务的商品刊例价格是100，用户选择了20元代金券、积分抵扣10元、立减10元，最终应付60元，此时创建的订单表4-1。
假设该订单一次性完成支付，不存在后付，基于订单信息生成生成如下账单记录，如表4-2所示：
该笔账单由多种支付方式完成支付，所有支付记录关联多条，如表4-3所示
支付处理
交易核心依托于支付记录向各个系统发起支付请求，本例子中包括外部渠道的支付请求，内部券的核销处理，积分的扣减等一系列支付处理。
- 微信支付：封装支付参数请求支付系统进行付款，成功后通知交易核心
- 代金券：封装券核销参数请求券系统锁定优惠券，待微信支付成功后核销优惠券
- 积分和立减的处理同优惠券
基于各系统返回的支付请求结果，更新支付流水状态；并更新账单为已支付；通知订单用户已完成付款，订单进入待发货或者待服务流程，如表4-4所示，这里要注意的时，此时外部渠道的支付方式才真正确定。
订单系统设计
雁过留声，人过留名；互联网业务呢，那就留下订单吧；订单是个常见的业务概念，我们去淘宝买东西、饿了么点外卖、微信服务里充话费、腾讯视频买会员等等，这些消费行为中我们都会得到一个订单。最直接的意义就是订单记录了我们的业务单据，买了什么，付了多少钱，平台交付了么，发货了么等，今天我们就详细分析下订单系统的设计。
基于业务订单系统
互联网产品肯定是先有了业务再有了系统，而不是先有了系统再有了业务；线下业务通过互联网实现了线上化，其中多样化的业务模型衍生出了众多的订单模型，比如电子商务的订单模型，包括实物订单模型和虚拟订单模型，纯支付交易的订单模型，外卖的订单模型等等；不同的订单模型下的订单设计存在稍微的差别，但从核心内容上讲依然存在相同的内核。我们通过图4-10可以了解这些不同环节的订单之间的关系。
无论什么样的业务，订单作为业务的记录凭证都有着相似的地方，可抽象的维度，可通用的设计框架，比如订单的父子订单，订单的拆分，订单的正向和逆向，订单的基本信息，订单的商品信息，用户信息，状态信息，支付信息，以及围绕业务订单产生的清算订单，资金订单，营销订单，物流订单等等。
对于订单流程不同的业务也有很大的差别，比如实物商品，收货就完结，还有一些比如家电还需要上门安装，就会衍生出服务单；虚拟商品也有支付成功就完结，也有需要上门服务的，比如上门保洁等，不同的业务会衍生出不同的子订单类型，也会有业务特点的订单流程。订单的状态也是一个设计的关键点，不同的订单模型会有不同的状态枚举和变更，比如常见的“生成订单--待付款-待发货-待收货--完成”，如果是服务单的话，可能还包括待服务等服务状态。
今天我们从电商平台的电商订单模型，支付公司的纯支付订单模型来分析订单系统的设计、订单模型特点、母订单和子订单、订单拆分、订单的正向和逆向流程以及订单的上下游关系等。
电商订单模型设计
电商订单是最具有代表意义的，模型最复杂，种类最多；一般电商下单的业务流程是这样的一用户在平台挑选好了商品后去结算，然后填写订单信息，提交订单以后便生成了电商的购物订单，这时候订单是待支付状态，支付成功后变成待发货，商家发货后订单变成待收货，确认收货后订单就完结了，后面如果发生了退换货就有了订单的逆向流程，而且在订单的中间环节也可以出现订单取消造成订单终止，比如用户没有进行付款造成订单超时未支付而关闭。订单的业务流程如图4-11所以。
这是一个最简化的电商订单流程，实际的订单还有更复杂的场景，比如买了多个商家的商品就面临着拆单，就有了子单的概念；对于一个子单如果有多个商品来自不同的库房，那么还需要进行拆分成不同的物流单，如果一个物流单中的几个商品形态差异太大比如冰箱和图书，那么还需要拆成多个包裹；另外如果订单支付的时候用到了积分，优惠券等其他支付组合，那么支付单也会有多个，会有多个支付流程。这些关系如图4-12所示。
用户下单
用户下单时，订单信息从各个系统获取基础数据并进行校验，最后封装生成订单；订单为基础推动其他相关系统生成其他对应的单据。
订单信息
订单需要记录一下相关维度的主要信息，基于业务模式的不同，可能需要增加其他辅助信息，这里主要介绍核心的订单信息内容：
- 谁买的：用户信息
- 买谁的：商家信息
- 买了什么：商品信息
- 钱怎么付的：支付信息
- 钱真的付了么：对账信息
- 发货了么：物流信息
- 上门安装了：服务信息
- 客诉了么：售后信息
- 破损了换一个吧：退换货信息
- 订单的旅程：订单日志
这些信息并不是存在一张数据表中，也不是简单的一对一的关系，各类信息可能需要存储在不通的表中，相互之间存在复杂的关联关系，如图4-13所示：
父子订单
如果用户在购物车选择了多个商家的商品时，会将本次购买拆分成多个商家的子订单；第一次支付时会对总订单进行支付；如果因为各种原因中断了，那么后面再进行支付时则对每个店铺的子订单进行支付，就是到订单列表可以看到多个待支付的子订单。
这是按照店铺去拆，当然也可以基于业务需要基于其他模型对订单进行拆分，拆分订单的目的是基于业务需要或者其他需要而设计。假如购买了2个商家的ABC三个商品，总价是100元，平台优惠20元，其中A商品属于店铺1，B商品属于店铺2。订单拆分后的父子订单之间往往存在如表4-5所示的关系。
优惠分摊
一个订单包含几个店铺的商品，每个店铺又有多个商品，而且在结算的时候又存在多个活动，有满减活动，优惠券，折扣等，如果这些优惠存在跨店铺情况，比如平台的满100减20，那么每个商家或者商品优惠了多少？退款的话怎么退，怎么与商家结算，财务如何记账；这时候我们就需要制定优惠的分摊策略，一般会把优惠拆分到sku上，也就是拆分到商品，因为用户可能会发起部分商品的退款，为了便于订单逆向处理以及优惠处理，拆分到商品更合适，也更公平。如表4-5中的优惠按照商品价格在订单商品总价的占比对优惠进行分摊子单1的优惠分摊金额 =(优惠20)*（商品金额20）/（商品总价100）=4。
订单状态
订单的状态记录了订单的变化以及流转，基于具体的业务需要设计订单的状态及变化逻辑，常见的订单状态包含一待付款，待发货，待收货，交易成功，已取消，售后中，订单关闭等，其流转关系如图4-14所示。
订单拆分
用户下单后，为了结算和售后方便，或者其他业务诉求，我们需要对订单进行拆分；一般影响拆单的因素有：平台的不同商家，发货仓库不同，品类特殊要求，物流因素，商品价值限制等。
- 不同商家：单独结算，商家单独发货
- 不同发货仓库：北京的仓库，天津的仓库
- 品类包装要求：易碎的需要特殊包装，大件小件分开包装
- 物流因素：物流公司对包裹的体积和重量有要求
- 商品限价：比如海购，海关有限价等。
所以拆单主要是两类，一类是下单时因为商家或者仓储问题拆成父订单和子订单，另一个是在发货时因为品类或者物流因素一个子订单拆成多个发货单，如图4-15所示：
其他电商类型订单
还有一些电商订单形态，比如服务单，像保洁月嫂上门服务，家电上门安装等，会有一个业务订单，用户进行支付，然后业务单拆出来服务单，可能一个订单需要3个师傅上门服务，那么就需要拆分出3个服务单，服务单主要是来控制服务的履约。
订单逆向
用户取消了订单，用户在支付成功后申请退款，用户收到货以后申请退货等等。
支付订单模型
还有另一个业务形态一三方支付公司的纯支付业务，包括收款、付款、商家提现等支付业务，这些业务也会生成订单，记录支付业务信息。但相对电商业务来说，支付业务的订单会有很多不同，例如没有实体商品，不需要发货收货，也就没有物流相关内容。我们将电商业务的订单关系移除业务订单以后剩下的部分适合与支付业务订单的关系表达，如图4-16所示：
基于支付公司的业务特点，将订单按照交易类型进行分类，比如收款订单，退款订单，清算订单，打款订单，营销订单，其他订单“鉴权认证，人网”等，所以订单范畴更广义。
收款订单
三方支付的收款订单，其实就是商户平台的商品下单支付请求过来的支付请求，业务流流程如图4-17所示：
订单路由
我们知道一个支付公司会有很多的支付产品，也可能存在多个处理系统，从而不同的订单类型在进行流转时会请求不同的系统，订单路由就是基于订单类型和基本信息选择要交互处理的系统，比如请求什么交易系统，请求那个结算系统等。
订单模型
交易订单，交易订单是总订单，会基于账户，营销拆成子订单，如表4-6所示
其他订单
其他类型订单大同小异，像退款订单，分账订单等，这里就不在赘述了，后面在交易系统以及清结算和账务的设计介绍时还会涉及到其他类型的订单。
订单服务
一个好的订单系统需要向上下游提供优质的订单服务，以及自身的订单处理业务，例如：
- 不同订单类型的创建服务
- 不同订单类型的查询服务
- 充，转，提，交易，退款等支付业务的回调通知服务
- 其他服务，比如补单，结算，订单分账等
订单后台
在理解了业务模型并设计好了订单模型以及订单系统的能力以后，再设计订单的展示层和运营操作层的后台，会变得非常容易。只需要搞清楚需要提供什么样的功能给运营赋能，展示什么样的订单信息，基于实际业务需求设计即可，例如：
- 订单管理：基本的工具是订单列表，可以通过不同的条件查询不同的订单等
- 信息展示：展示订单的基本信息，商品信息，状态信息，支付信息等
- 系统关联：可以关联到支付系统查看支付详情，可以关联到用户中心查看用户信息等
换句话说，先有了业务再有了系统，先有了运营体系再有了系统的运营赋能，没必要追求现成的系统设计模板，可以尝试建立灵活的设计观念，基于业务模型设计出满足业务诉求的订单系统来。
