Go支付订单聚合领域建模与架构设计 - 第1节
1.1 支付系统核心概念
支付系统是连接用户、商户与金融机构的数字化价值交换网络。理解其核心概念是构建聚合支付领域模型的基础。
1.1.1 支付参与方
| 参与方 | 角色定义 | 典型实体 |
|---|---|---|
| 付款方 | 发起支付指令的资金提供者 | 消费者、企业采购员 |
| 收款方 | 接收资金的商品或服务提供者 | 电商商户、线下门店 |
| 支付机构 | 提供支付通道与清算服务的中间方 | 支付宝、支付、银联 |
| 清算组织 | 负责跨机构资金对账与结算 | 网联、银联清算中心 |
| 监管机构 | 制定规则并监督合规 | 中国人民银行、外汇管理局 |
1.1.2 支付核心要素
- 订单：交易的核心载体，包含商品信息、金额、状态等字段。
- 交易流水：每笔支付请求的原始记录，不可篡改。
- 支付凭证：支付机构返回的确认凭据（如支付宝交易号）。
- 对账单：支付机构定期提供的资金结算明细文件。
- 退款：逆向资金流转，需与原订单关联。
领域建模提示： 在 DDD 中，订单 和 交易流水 通常作为聚合根存在，而 支付凭证 是值对象。区分实体与值对象是划分领域边界的第一步。
1.2 支付链路全景
一笔完整的支付从用户发起到资金到账，经历多个环节。下图展示了标准支付链路的核心阶段：
1.2.1 链路关键阶段详解
- 用户下单：商户系统创建订单，生成唯一订单号与支付金额。
- 支付请求：用户选择支付方式，系统组装支付参数并调用支付网关。
- 路由选择：根据金额、渠道状态、费率等规则，动态选择最优支付通道。
- 渠道处理：与第三方支付机构交互，完成扣款、授权或签约操作。
- 结果通知：接收支付结果，更新订单状态，触发后续业务（如发货）。
常见陷阱： 支付结果通知可能延迟、重复或丢失。系统必须实现 幂等处理 和 定时对账补偿 机制，不能依赖单次通知的可靠性。
1.3 聚合支付的定义与价值
1.3.1 什么是聚合支付
聚合支付（Aggregate Payment）是指通过一个统一的平台，集成多家支付机构的支付能力，为商户提供一站式支付接入服务。商户无需分别对接支付宝、、银联等渠道，只需对接聚合平台即可。
| 对比维度 | 直连模式 | 聚合支付模式 |
|---|---|---|
| 对接成本 | 高：每家渠道独立开发、测试、维护 | 低：一次对接，多通道可用 |
| 运维复杂度 | 高：需监控多个渠道的接口变更 | 低：聚合平台统一处理升级 |
| 资金结算 | 多对多：各渠道分别结算 | 一对多：聚合平台统一结算 |
| 故障容灾 | 弱：单渠道故障影响该通道交易 | 强：自动切换备用通道 |
1.3.2 聚合支付的核心价值
- 降低接入门槛：商户只需集成一套 API，即可支持多种支付方式。
- 提升支付成功率：智能路由在渠道故障或超时时自动切换，减少支付失败。
- 统一对账与报表：所有渠道的交易数据汇总在一个平台，便于财务核算。
- 灵活扩展：新增支付渠道时，商户端无需改动，仅由聚合平台适配。
领域驱动视角： 聚合支付的核心领域模型应围绕 支付订单聚合 展开，将渠道适配、路由策略、对账逻辑封装在领域服务中，保持商户端接口的稳定与简洁。
1.4 聚合支付系统架构概览
下图展示了聚合支付系统的分层架构，帮助理解各模块在领域边界中的位置：
1.4.1 各层职责说明
| 层级 | 核心职责 | 领域边界 |
|---|---|---|
| 接入层 | 对外暴露统一 API，处理鉴权、限流、协议适配 | 属于应用层，不包含业务逻辑 |
| 业务层 | 订单聚合、支付指令、路由决策、对账引擎 | 核心领域层，是 DDD 建模的重点 |
| 渠道层 | 封装各支付机构的协议差异，提供统一接口 | 属于基础设施层，通过端口适配器模式隔离 |
| 基础设施层 | 提供持久化、缓存、消息、监控等通用能力 | 支撑层，不包含业务语义 |
课程聚焦： 本课程将重点围绕 业务层（Order Domain） 展开，使用 Go 语言实现支付订单聚合的领域模型、路由策略与对账引擎，并展示如何通过 DDD 的战术设计（实体、值对象、领域服务、聚合）来构建高内聚低耦合的支付核心系统。