MVP 实战：再造一个“支付宝”

在前文《支撑 MVP，架构师需要做什么》中，介绍了怎么通过 MVP 的选取，控制产品和机构的 scope，用最短的节奏完成功能的交付。但是，理论是枯燥难懂的。本文我们通过一个钱包建设的过程，来看一下怎么通过选取 MVP 的方式来快速启动一个产品的建设，以及 MVP 建成后续产品和架构应该怎么演化。

MVP 范围的确定

首先，为了快速启动产品的建设，尽快的上线并进入 Pilot 阶段，我们需要控制产品第一个迭代的范围。同时，交付的产品又必须是一个真实可用并完整的。

对于一个钱包，所必须的最小功能集是什么呢？

• 首先，必须有一个余额（Balance）管理的能力。钱包不是卡包，如果没有余额，就不称其为钱包了。

• 其次，余额不是凭空出现的，必须有充值（Topup）的能力。

• 最后，余额需要能够使用，所以必须有简单的余额支付（Payment）能力。

为了控制产品的规模，其余的功能，包括用户管理、商户管理等，都可以先不在 MVP 中出现，可以通过离线和人工的手段先支撑。比如用户注册由于是 Pilot 阶段，可以先采用人工初始化的方式，用户 KYC 和商户 KYB 可以通过人工审核的手段，对商户的结算可以用离线清洗数据的方式。

先来看余额管理的能力。要支持余额管理，我们需要有一个对用户的标识，以及一个用户余额的累积以及余额变动明细。所以就会出现三个实体：

• 用户（User），描述钱包的归属自然人。

• 账户（Account），用户开设的钱包以及纪录钱包余额。后续可以支撑一个用户开始多个账户（多币种/多用途等）。

• 账务变动明细（Account Detail），用户每次的动账记，包括入账（Dr）和出账（Cr）。

再来看充值，我们可以先支持银行卡的充值，先不支持线下充值、手机充值、其他钱包转账等其他方式。

要支持充值，就必须和银行机构（网联）交互。一次充值是对账户的一次变动，是一个 Transaction。

• 充值订单（TopupOrder），纪录每次发起的充值行为。

• 和机构的交互（CompositeTransaction），纪录和机构的一次完整交互生命周期，目前和 TopupOrder 是一对一的关系。

• 和机构的原子交互（AtomicTransaction），有的时候和机构的交互需要有多次的请求，或者还有查询操作和反向的补偿操作，所以需要有原子单来记录美次交互，同时保存和组合单之间的一对多关系。

• TopupOrder 和 AccountDetail 之间需要有关联关系。

最后看一下支付，目前的支付比较简单，只能是余额支付。

但是我们需要记录商户下单的过程，还需要根据这个商户单据和商户进行结算（离线）。

• 商品订单（AcquireOrder），记录商户的每次下单过程。同时需要有 Item 记录其中的每个分项，支持多个商品同时下单的方式（MP 中暂不实现）。

• 支付单（PaymentOrder），针对商品订单的支付行为，目前是一对一关系，可扩展为一对多。

至此，MVP 的范围和支撑 MVP 的模型已经 ok。对外的服务，主要需要有如下：

• 和机构交互所需的服务，包括调用机构 API 和机构需要我们实现的 callback。

• 商户下单服务。

• 用户确认支付的交互。

• 用户注册、商户入驻、商户结算、机构对帐在 MVP 中暂时不实现，采用人工的方式支持。

第一轮升级

Pilot 完成后，我们发现我们的钱包是稳定可用的。但是，一个只能充值和余额支付的钱包，同时用户注册、商户入驻、结算清算都是人工操作，是基本没办法大规模展业的。

接下来面临一次大的升级。升级的方向是什么呢？这就要看我们的商业决策。如果决策是要扩大日活用户（DAU）和日均交易（DAT），那么那些人工的操作就必须有自动化支撑。如果决策是需要扩大功能范围从而更好的吸引用户，那又是另外一条升级路径了。

假设我们的决策是要先丰富功能，厚积薄发。

第一轮升级涵盖的范围：

• 增加充值途径，包括钱包和线下。

• 增加支付方式，增加其他钱包和信用卡。

• 增加费用的优惠，包括打折、券和年卡。

首先，我们看增加充值途径，这个无非就是增加 Topup 的渠道。TopupOrder 模型基本可以不变，只需要增加枚举记录充值类型。和外部渠道组合单和原子单的模型也不用变化。这里需要增加的就是对不同机构的 API 的集成。

其次，增加支付方式，由于增加了外部支付方式，我们需要模型来记录外部资产。

• 支付资产（PaymentAsset），同时可以将余额也抽象为一类资产。

• 外部支付需要和机构/外部钱包有交互。这里可以复用组合单和原子单的模型。但是组合单模型需要升级，不光可以和 TopupOrder 关联，也需要能支持 PaymentOrder。

• 考虑到后续可能还有组合支付，将 PaymentOrder 模型扩展，增加支付指令（PaymentInstruction），来记录一次对支付资产的操作，PaymentInstruction 和 AccountDetail 或者组合单关联。

最后，看一下费用优惠的支撑，这部分是改动最大的。原先的费用，可能就是在 PaymentOrder 中的一个费用字段。引入费用优惠后，

• 首先，需要有一个费用模型，独立于支付单，记录费用计算的要素和结果。

• 其次，针对费用优惠券和费用年卡，增加券（Coupon）模型。

• 增加计费策略（FeeStrategy）模型，支持对不同费用收取类型的抽象。

第二轮升级

功能的扩展完成了，下面就要获客和促活。前面一些人工的操作需要自动化的产品能力来支撑。

第二轮升级的点包括：

• 核算

• 用户/商户管理，KYC/KYB

• 登录、验真体系完善

• 商户结算能力自动化。

• 和机构自动化对帐能力。

核算，这个可以采购或新增 Accounting 系统，主要就是针对所有的业务操作，进行核算反映，采用复式记账的方式进行记账。主要的模型包括账户、科目、流水账、总账。同时在核算的基础上，可以通过离线的方式出具各类所需报表。

用户商户管理，包括扩展 User 模型，纪录用户/商户更详细的信息，我们可以成为认证信息（Certification）。同时针对 KYC、KYB，建立相应的单据、流程来支撑。

登录能力包括用户登录所用的账密信息、安全验证信息、联系方式等。

针对和机构的交互，建立加签验签所需的密钥管理体系。

商户结算能力，通过对商品订单的清洗，形成结算订单（SettlementOrder），定义结算策略（SettlementStrategy），采用日结/月结的方式，给商户自动进行结算。同时需要记录结算资产（结算卡），打款时利用前面建设的渠道能力，并通过结算指令完成（SettlementInstruction）。

机构自动化对帐能力，需要建设明细和汇总两方面的能力。纪录机构的清算文件，通过离线清洗的方式进行汇总对帐。同时接收银行的 052/053 文件，进行账户资金变动的核对。需要建设机构账单模型。

后续的升级方向

后续，钱包可能需要支持跨境的交易，支持币种的兑换；需要支持扫码支付；需要支持接入收单机构。这些在模型和服务上的拓展应该怎么进行，这里先留给读者思考。由于这三个方向每个都比较大，后续单独进行阐述。