首先，聊一下我个人对于交易支付系统的理解，从用户的角度来说，交易支付是密不可分的行为，但是对于系统来说，交易支付应该是两个系统，有些系统建设时，甚至是没有交易系统的，直接由业务系统调用本地支付模块，或者第三方支付完成支付。这种设计在流量不大的情况，可能没什么问题，但是随着公司业务发展、规模扩大，这种方式无疑不利于后期的系统维护和扩展。而交易系统本身作为一个底层系统，应该统一抽象出完整的交易能力，供公司其他业务调用。统一业务收口，一般由交易系统、或者是收单系统负责，这里插一句，收单指的签约银行向商户提供的本外币资金结算服务，这里的收单是一个泛指含义。收单系统和交易系统的区别是，收单更多的是关注业务上的要素，而交易系统则更多去关心交易这件事。
下图是我自己XJB画的，0.0 ...
整体上看的话，一个完整的交易支付体系，包含了三个层次：
- 支付核心系统
- 交易系统：提供最基础的交易支付能力，充转提退：充值、转账、提现、退款
- 账务系统：提供账户管理、记账凭证、余额查询等
- 清算平台：提供清算、计费、对账和差错的能力
- 资金管理平台：资金调拨、资金池管理等
- 收银台：支付渠道管理、支付工具选择、额度控制
- 会计系统：会计分录、科目汇总、发票系统等
- 支付支撑系统
- 渠道网关：签约、加密、验签、支付结果通知等
- 公共组件：
- 会员系统
- 风控系统
- 短信平台
- 监控平台
- 数据归集
上面是整个交易支付系统的相关组件，不同的业务可以根据自己不同的业务来进行相应调整，但是核心系统不可或缺：
面向支付业务的话：交易核心、收银台、支付核心、渠道网关
面向资金业务：账务系统、清结算系统、会计系统等
其他还会有一些基础组件，在此不再赘述。
这边会重点介绍一下支付业务相关的基础组件（因为本人一直从事这方面相关开发），后续也会介绍一些资金相关的系统建设（我会尽量去了解哈~）。
首先先说交易系统，交易系统对外提供交易能力，大的交易能力可以抽象为：充值、转账、提现、退款，四种大的交易类型下，又可以区分出不同的子交易类型，具体和业务相关联。抽象出交易能力的好处是，将业务和交易剥离，我就见过在交易逻辑中耦合大量业务逻辑的系统，不仅代码维护起来十分的困难，而且也不便于后期扩展，从领域设计的角度来说，交易域更关心交易相关的要素，而对外屏蔽业务相关。这样的好处是：面对于频发性的业务改动，交易系统始终提供统一的交易能力，可以适配各个业务的扩展。
同时，为了交易数据整体的关联，建议统一订单模型抽象，整条链路关联到一个交易单上，该交易单全链路唯一，并且能关联到所有的交易、支付、用户等信息。这样就初步搭建起一个交易系统。
