3. 支付领域全景：支付核心链路（下单、支付、退款、对账）的领域划分

在构建支付订单聚合之前，必须从领域全景视角理解支付系统的核心链路。支付领域并非单一业务，而是由多个相互协作的限界上下文（Bounded Context）构成。本章将围绕“下单 → 支付 → 退款 → 对账”四大核心链路，明确每个环节的领域边界、核心职责与交互关系。

3.1 支付核心链路全景图

下图展示了支付领域的四大核心阶段及其所属的限界上下文。每个阶段都有独立的领域模型和聚合根，通过领域事件或应用服务进行协作。

支付核心链路领域划分全景图 支付核心链路领域划分全景图 下单 交易上下文 支付 支付上下文 退款 退款上下文 对账 对账上下文 核心聚合根 订单聚合（Order） 支付单聚合（Payment） 退款单聚合（Refund） 对账批次聚合（Recon） 关键领域事件（跨上下文通信） OrderCreated PaymentCompleted RefundFinished ReconCompleted 💡 领域边界说明： • 每个上下文拥有独立的数据库和聚合根，避免跨上下文直接访问数据。 • 上下文之间通过领域事件（Domain Event）进行异步解耦，例如支付完成后发布 PaymentCompleted 事件。 • 订单聚合是全局入口，支付单聚合负责资金处理，退款单聚合处理逆向资金，对账聚合保证数据一致性。 • 每个上下文内部可进一步拆分为子域（如支付上下文包含渠道网关、风控、记账等子域）。

3.2 下单阶段：交易上下文

下单是支付链路的起点，由交易上下文（Trade Context）负责。该上下文的核心职责是创建订单、校验商品库存、计算金额并生成待支付订单。

3.2.1 核心聚合：订单聚合（Order Aggregate）

元素 说明
聚合根 Order（订单实体）
核心值对象 OrderId、Money、OrderStatus、PaymentMethod
关键行为 CreateOrder()、CancelOrder()、ConfirmOrder()
领域事件 OrderCreated、OrderCancelled、OrderConfirmed
边界 不包含支付渠道信息，只记录支付方式类型

3.2.2 下单流程关键步骤

  1. 校验库存与价格：调用商品上下文获取最新库存和价格。
  2. 创建订单聚合：生成订单 ID，设置初始状态为 PENDING_PAYMENT。
  3. 发布 OrderCreated 事件：通知支付上下文开始处理支付。
  4. 返回订单信息：将订单 ID 和支付链接返回给客户端。
领域边界要点：交易上下文不关心支付渠道、不处理资金流水。它只负责订单的生命周期管理。支付上下文通过监听 OrderCreated 事件来启动支付流程。

3.3 支付阶段：支付上下文

支付上下文是支付系统的核心，负责处理资金的实际流转。它管理支付单、调用外部渠道、记录资金流水，并最终完成支付。

3.3.1 核心聚合：支付单聚合（Payment Aggregate）

元素 说明
聚合根 Payment（支付单实体）
核心值对象 PaymentId、ChannelId、Amount、PaymentStatus、TransactionRecord
关键行为 StartPayment()、ProcessCallback()、HandleTimeout()
领域事件 PaymentStarted、PaymentCompleted、PaymentFailed
边界 不直接操作订单状态，通过事件驱动订单上下文

3.3.2 支付流程关键步骤

  1. 接收 OrderCreated 事件：创建支付单聚合，状态为 INIT。
  2. 选择支付渠道：根据支付方式、金额、风控规则选择渠道。
  3. 调用渠道网关：发起支付请求，获取支付凭证。
  4. 处理异步回调：接收渠道回调，更新支付单状态。
  5. 发布 PaymentCompleted 事件：通知交易上下文和退款上下文。
关键设计决策：支付单聚合内部维护一个 TransactionRecord 值对象列表，记录每次渠道交互的流水。这保证了支付单的完整审计轨迹，且不依赖外部日志系统。

3.4 退款阶段：退款上下文

退款是支付的反向流程，由退款上下文（Refund Context）管理。它负责处理退款申请、调用渠道退款接口、管理退款状态。

3.4.1 核心聚合：退款单聚合（Refund Aggregate）

元素 说明
聚合根 Refund（退款单实体）
核心值对象 RefundId、OriginalPaymentId、RefundAmount、RefundStatus、RefundReason
关键行为 ApplyRefund()、ProcessRefundCallback()、CancelRefund()
领域事件 RefundApplied、RefundCompleted、RefundFailed
边界 不直接修改支付单状态，通过事件同步退款结果

3.4.2 退款流程关键步骤

  1. 接收退款请求：校验退款金额不超过原支付金额。
  2. 创建退款单聚合：状态为 PENDING。
  3. 调用渠道退款接口：发起退款请求。
  4. 处理退款回调：更新退款单状态为 SUCCESS 或 FAILED。
  5. 发布 RefundCompleted 事件：通知交易上下文更新订单状态。
常见陷阱：退款上下文不应直接访问支付单数据库。正确的做法是通过支付上下文提供的查询接口或领域事件获取支付信息。跨上下文直接访问会导致聚合边界被破坏，引发数据不一致。

3.5 对账阶段：对账上下文

对账是支付系统的“最后一道防线”，由对账上下文（Reconciliation Context）负责。它确保系统内部记录与外部渠道记录一致，发现并处理差异。

3.5.1 核心聚合：对账批次聚合（ReconBatch Aggregate）

元素 说明
聚合根 ReconBatch（对账批次实体）
核心值对象 BatchId、ChannelId、Date、ReconStatus、ReconDiffItem
关键行为 StartRecon()、CompareRecords()、GenerateDiffReport()
领域事件 ReconStarted、ReconCompleted、ReconDiffFound
边界 只读取支付上下文和退款上下文的流水数据，不修改

3.5.2 对账流程关键步骤

  1. 拉取渠道对账单：从支付渠道获取对账文件。
  2. 拉取系统流水：从支付上下文和退款上下文获取当日流水。
  3. 逐笔比对：比对金额、状态、时间等字段。
  4. 生成差异报告：标记长款、短款、状态不一致等差异。
  5. 发布 ReconCompleted 事件：通知运营系统处理差异。

3.6 四大上下文对比总结

维度 交易上下文 支付上下文 退款上下文 对账上下文
核心聚合 Order Payment Refund ReconBatch
主要职责 订单生命周期 资金支付处理 逆向资金处理 数据一致性校验
数据存储 订单数据库 支付流水库 退款流水库 对账结果库
对外依赖 商品上下文 支付渠道网关 支付渠道网关 渠道对账文件
领域事件 OrderCreated PaymentCompleted RefundCompleted ReconCompleted
事务边界 强一致性（本地事务） 最终一致性（事件驱动） 最终一致性（事件驱动） 最终一致性（批量处理）

3.7 上下文协作关系图

下图展示了四个上下文之间的领域事件驱动协作关系，以及每个上下文对外部系统的依赖。

支付领域上下文协作关系图 支付领域上下文协作关系图 交易上下文 订单聚合 支付上下文 支付单聚合 退款上下文 退款单聚合 对账上下文 对账批次聚合 OrderCreated PaymentCompleted RefundCompleted 外部依赖 商品上下文 支付渠道网关 支付渠道网关 渠道对账文件 💡 协作规则： • 交易上下文 → 支付上下文：通过 OrderCreated 事件触发支付流程。 • 支付上下文 → 退款上下文：通过 PaymentCompleted 事件提供退款依据。 • 对账上下文：只读方式访问支付和退款流水，不修改任何业务数据。 • 所有跨上下文通信必须通过领域事件或应用服务接口，禁止直接访问数据库。

3.8 领域边界设计原则

  • 单一职责：每个上下文只负责一个核心业务能力，不越界。
  • 数据所有权：每个上下文拥有自己的数据库，其他上下文只能通过接口或事件访问。
  • 事件驱动：上下文之间通过领域事件实现最终一致性，避免分布式事务。
  • 聚合边界：每个聚合根负责维护自身的不变规则，不依赖外部聚合的状态。
实战建议：在 Go 项目中，每个上下文可以作为一个独立的 Go Module，拥有自己的 domain、application、infrastructure 包。上下文之间通过事件总线（如 RabbitMQ、Kafka）或 gRPC 接口通信。后续章节将深入每个上下文的聚合设计与 Go 实现。
← 上一章 📖 返回目录 下一章 →