用 DDD 梳理跨境收付款产品

先不急着写功能列表，也不急着画页面。跨境收付款产品的难点不在某个按钮，而在领域概念很多、边界很硬、状态变化很长。用 Domain-Driven Design 先把语言、边界和核心流程梳理清楚，后面的 Spec、原型和代码才不会散。

这部分内容会从领域知识开始，而不是从实现开始。

目标

建立一套能指导产品设计和工程实现的领域模型：

• 用统一语言描述商户、客户、订单、支付、收款、付款、换汇、清算、结算、退款、拒付、对账和合规审查。
• 找出跨境收付款产品的核心子域、支撑子域和通用子域。
• 拆出有边界的上下文，避免把支付、账务、风控、合规、通知和运营揉成一个大模块。
• 梳理关键状态机，让每一笔资金相关流程都可追踪、可解释、可对账。
• 最终沉淀为产品 Spec、数据模型、API 设计和验收标准。

统一语言

先把常用词说清楚。后续所有文档、代码命名、页面文案都尽量沿用这些词。

术语	含义
商户	使用平台收款或付款的业务主体，可以是公司、个体或平台卖家。
客户	向商户付款的买家、订阅用户或业务合作方。
交易	一次业务层面的资金请求，例如一笔订单收款或一笔供应商付款。
支付	客户完成付款动作的过程，关注支付方式、授权、失败原因和确认结果。
收款	商户从客户侧获得资金的业务能力。
付款	商户向供应商、员工、创作者或合作方付出资金的业务能力。
换汇	不同币种之间的金额转换，包含汇率、点差、锁汇和有效期。
清算	支付通道、银行或合作机构确认资金结果并形成可结算金额的过程。
结算	平台将可结算资金划拨给商户或指定收款方的过程。
对账	将订单、支付通道、账务流水、银行入账和结算结果进行匹配。
退款	对已成功收款交易进行部分或全额退回。
拒付	持卡人或发卡机构发起争议，可能导致资金被撤回。
合规审查	对商户、交易、收款方、地区、行业和资金用途进行风险判断。

子域划分

核心子域

这些是产品能否成立的关键：

• 收款编排：根据国家、币种、金额、支付方式、商户风险等级选择通道。
• 付款编排：处理收款方、币种、费用、到账时间、失败重试和合规限制。
• 账务与余额：记录可用余额、冻结金额、在途金额、手续费、汇差和调整。
• 对账与异常：识别订单、通道、账务、银行和结算之间的不一致。
• 风控与合规策略：决定哪些商户、交易或收款方需要拦截、复核或增强验证。

支撑子域

这些能力很重要，但服务于核心流程：

• 商户入驻与 KYB。
• 客户与收款方管理。
• 费率、汇率和报价。
• 通知、邮件和 Webhook。
• 运营审核后台。
• 报表和导出。

通用子域

可以复用成熟方案，不需要自己创造复杂模型：

• 用户、角色和权限。
• 审计日志。
• 文件上传。
• 消息队列。
• 基础配置中心。

限界上下文

第一版先拆成这些上下文：

上下文	负责什么	不负责什么
Merchant	商户资料、业务信息、KYB 状态、风险等级	具体交易执行
Payment	收款请求、支付方式、通道结果、支付状态	商户余额和会计分录
Payout	付款请求、收款方、付款通道、到账结果	收款交易的支付授权
Ledger	余额、流水、冻结、解冻、手续费、调整	通道选择和合规判断
FX	汇率报价、币种转换、报价过期	真实资金划拨
Compliance	制裁名单、地区限制、行业限制、审核任务	账务入账
Reconciliation	文件导入、流水匹配、差异处理	业务规则审批
Notification	邮件、站内信、Webhook、回调重试	决策交易是否成功

核心流程草图

跨境收款

1. 商户创建收款交易。
2. 系统根据地区、币种、金额和风险策略选择支付方式与通道。
3. 客户完成支付授权。
4. 通道返回成功、失败、处理中或需额外验证。
5. 系统生成账务流水，资金进入在途或冻结状态。
6. 清算文件到达后，对账系统确认通道结果。
7. 可结算金额进入商户余额。
8. 若出现退款、拒付或差异，进入异常处理流程。

跨境付款

1. 商户创建付款请求。
2. 系统校验余额、收款方、币种、国家和合规限制。
3. 如涉及换汇，生成汇率报价并锁定有效期。
4. 审核通过后冻结付款金额和费用。
5. 付款通道执行出款。
6. 根据通道结果更新付款状态。
7. 成功则记账完成，失败则解冻或进入人工处理。
8. 银行或通道文件到达后完成对账。

关键状态机

收款交易状态

created -> pending_payment -> processing -> succeeded
                                      -> failed
                                      -> requires_action
succeeded -> refundable -> partially_refunded -> refunded
succeeded -> disputed -> dispute_won
                       -> dispute_lost

付款状态

created -> compliance_checking -> approved -> funds_frozen -> processing -> paid
                                -> rejected
processing -> failed -> retrying
                  -> returned

对账差异状态

detected -> assigned -> investigating -> resolved
                              -> written_off
                              -> escalated

接下来要回答的问题

• 我们第一阶段服务哪类商户：跨境电商、独立站、SaaS、内容创作者，还是 B2B 服务商？
• 第一阶段只做收款、只做付款，还是先做不碰资金的对账和运营工具？
• 哪些能力必须依赖持牌机构，哪些可以作为 SaaS 工具独立提供？
• 账务模型要支持哪些币种、哪些余额类型、哪些冻结原因？
• 异常处理的人工运营台需要记录哪些证据、备注和审批动作？
• 哪些状态变化必须写入审计日志，哪些事件必须通知商户？

输出物

DDD 梳理完成后，下一步会形成：

• 领域词典。
• 上下文地图。
• 核心实体和值对象清单。
• 聚合与领域事件。
• 状态机和异常流程。
• 第一版产品 Spec。