2. 支付订单领域分析

支付订单是支付系统的核心聚合根，承载着从用户发起支付到资金最终结算的完整过程。本章从业务场景、生命周期和状态机三个维度，深入剖析支付订单的领域边界与行为规则。

2.1 支付订单的核心业务场景

支付订单并非孤立存在，它服务于多个业务场景。理解这些场景有助于我们界定聚合的职责边界。

2.2 支付订单的生命周期

支付订单从创建到最终完成（成功或关闭）经历多个阶段。下图展示了完整的生命周期流转路径。

2.3 支付订单的状态机设计

状态机是支付订单聚合的核心行为模型。它定义了每个状态下允许的事件、转移规则以及边界条件。以下是支付订单的完整状态机定义。

2.3.1 状态定义表

2.3.2 状态转移规则

状态转移必须满足以下领域规则，任何违反规则的转移都应被聚合根拒绝。

• 规则 1： 只有 PENDING 状态的订单可以发起支付，进入 PROCESSING。
• 规则 2： PROCESSING 状态只能转移到 SUCCEEDED 或 FAILED，不允许直接关闭。
• 规则 3： FAILED 状态允许重试，重试次数上限为 3 次，超过后自动进入 CLOSED。
• 规则 4： SUCCEEDED 状态可发起退款，退款完成后进入 REFUNDED。
• 规则 5： CLOSED 和 REFUNDED 为终态，不可再发生任何状态转移。
• 规则 6： 任何状态转移都必须记录事件日志，用于对账和审计。

2.3.3 状态机代码骨架（Go + Ent）

以下代码展示了使用 Go 语言实现支付订单状态机的核心逻辑。实际项目中，状态机逻辑应封装在聚合根的方法内。

// PaymentOrder 支付订单聚合根
type PaymentOrder struct {
    ID          string
    Amount      decimal.Decimal
    Status      PaymentStatus
    RetryCount  int
    CreatedAt   time.Time
    UpdatedAt   time.Time
}

// PaymentStatus 支付状态枚举
type PaymentStatus string

const (
    StatusPending    PaymentStatus = "PENDING"
    StatusProcessing PaymentStatus = "PROCESSING"
    StatusSucceeded  PaymentStatus = "SUCCEEDED"
    StatusFailed     PaymentStatus = "FAILED"
    StatusClosed     PaymentStatus = "CLOSED"
    StatusRefunded   PaymentStatus = "REFUNDED"
)

// StartPayment 发起支付：PENDING -> PROCESSING
func (o *PaymentOrder) StartPayment() error {
    if o.Status != StatusPending {
        return fmt.Errorf("cannot start payment from status: %s", o.Status)
    }
    o.Status = StatusProcessing
    o.UpdatedAt = time.Now()
    // 记录领域事件
    o.AddEvent(PaymentStarted{OrderID: o.ID})
    return nil
}

// MarkSucceeded 支付成功：PROCESSING -> SUCCEEDED
func (o *PaymentOrder) MarkSucceeded() error {
    if o.Status != StatusProcessing {
        return fmt.Errorf("cannot mark succeeded from status: %s", o.Status)
    }
    o.Status = StatusSucceeded
    o.UpdatedAt = time.Now()
    o.AddEvent(PaymentSucceeded{OrderID: o.ID})
    return nil
}

// MarkFailed 支付失败：PROCESSING -> FAILED
func (o *PaymentOrder) MarkFailed() error {
    if o.Status != StatusProcessing {
        return fmt.Errorf("cannot mark failed from status: %s", o.Status)
    }
    o.Status = StatusFailed
    o.RetryCount++
    o.UpdatedAt = time.Now()
    o.AddEvent(PaymentFailed{OrderID: o.ID, RetryCount: o.RetryCount})
    return nil
}

// RetryPayment 重试支付：FAILED -> PROCESSING
func (o *PaymentOrder) RetryPayment() error {
    if o.Status != StatusFailed {
        return fmt.Errorf("cannot retry from status: %s", o.Status)
    }
    if o.RetryCount >= 3 {
        return fmt.Errorf("max retry count exceeded: %d", o.RetryCount)
    }
    o.Status = StatusProcessing
    o.UpdatedAt = time.Now()
    o.AddEvent(PaymentRetried{OrderID: o.ID, RetryCount: o.RetryCount})
    return nil
}

// Close 关闭订单：PENDING/FAILED -> CLOSED
func (o *PaymentOrder) Close() error {
    if o.Status != StatusPending && o.Status != StatusFailed {
        return fmt.Errorf("cannot close from status: %s", o.Status)
    }
    o.Status = StatusClosed
    o.UpdatedAt = time.Now()
    o.AddEvent(PaymentOrderClosed{OrderID: o.ID})
    return nil
}

// Refund 退款：SUCCEEDED -> REFUNDED
func (o *PaymentOrder) Refund() error {
    if o.Status != StatusSucceeded {
        return fmt.Errorf("cannot refund from status: %s", o.Status)
    }
    o.Status = StatusRefunded
    o.UpdatedAt = time.Now()
    o.AddEvent(PaymentRefunded{OrderID: o.ID})
    return nil
}

2.3.4 状态机可视化

下图以状态机图的形式，清晰展示了所有允许的状态转移路径。