4. 状态机设计原则：单一职责、开闭原则、状态显式化、避免状态爆炸

在聚合支付系统的状态机建模中，设计原则直接决定了模型的正确性、可维护性和扩展性。支付状态机涉及交易、退款、对账、结算等多个子域，若缺乏原则约束，极易出现状态混乱、逻辑耦合、难以演进等问题。本节围绕四个核心设计原则展开，帮助你在实际建模中做出高质量决策。

4.1 单一职责原则：每个状态机只负责一个业务聚合

单一职责原则（Single Responsibility Principle, SRP）要求一个状态机只描述一个业务聚合的生命周期。在支付系统中，常见的错误是将“支付订单”和“退款订单”的状态混入同一个状态机，导致状态数量膨胀、转换条件复杂。

4.2 开闭原则：对扩展开放，对修改封闭

开闭原则（Open/Closed Principle, OCP）在状态机设计中体现为：新增支付渠道或业务场景时，不应修改已有状态定义和转换逻辑。支付系统经常需要接入新渠道（如、支付宝、银联），每个渠道可能有独特的中间状态（如“等待用户扫码”、“银行处理中”）。

实现开闭原则的常用手段：

• 状态扩展点：在状态机定义中预留“子状态”或“扩展状态”槽位，新渠道只需注册自己的子状态，不修改主状态机。
• 事件路由：使用事件分发器将渠道特定事件路由到对应的状态处理器，主状态机只处理通用事件。
• 策略模式：将状态转换的校验逻辑封装为策略接口，新渠道实现该接口即可。

// 开闭原则示例：状态转换策略接口
public interface PaymentStateTransitionStrategy {
    boolean canTransition(PaymentState current, PaymentEvent event, PaymentContext context);
}

// 渠道实现
public class WechatTransitionStrategy implements PaymentStateTransitionStrategy {
    @Override
    public boolean canTransition(PaymentState current, PaymentEvent event, PaymentContext context) {
        // 特有的状态校验逻辑
        return true;
    }
}

4.3 状态显式化：用枚举或常量定义所有状态，避免隐式状态

状态显式化原则要求：所有可能的状态值必须在代码中以枚举或常量形式明确列出，不允许使用字符串、数字或数据库字段值隐式表示状态。隐式状态是状态爆炸和逻辑错误的温床。

以下是一个支付订单状态枚举的典型定义：

public enum PaymentState {
    // 初始状态
    INIT,
    // 支付流程
    PENDING_PAYMENT,
    PAYING,
    PAID,
    PAY_FAILED,
    // 退款流程（仅记录，实际由退款状态机管理）
    REFUNDING,
    REFUNDED,
    // 终态
    CLOSED,
    CANCELLED
}

4.4 避免状态爆炸：通过状态分层、子状态机、状态压缩控制复杂度

状态爆炸是指状态数量随着业务复杂度增长而失控，导致状态转换矩阵难以维护。聚合支付系统中，渠道差异、业务类型、风控介入等因素极易引发状态爆炸。

控制状态爆炸的三种策略：

1. 状态分层：将状态分为“主状态”和“子状态”。主状态控制在 5-8 个，子状态用于描述渠道或场景细节。
2. 子状态机：将复杂流程拆分为独立的状态机实例。例如“支付中”状态内部可以嵌套一个“渠道交互状态机”。
3. 状态压缩：合并语义等价的状态。例如“支付超时”和“支付取消”在业务上可合并为“已关闭”。

4.5 原则综合应用：支付状态机设计示例

以下是一个遵循上述四个原则的支付订单状态机设计示例，包含主状态定义、子状态扩展和状态转换表。

4.6 原则检查清单

在完成状态机设计后，使用以下清单进行自检：

• 单一职责：该状态机是否只描述一个业务聚合的生命周期？是否混入了退款、对账等其他聚合的状态？
• 开闭原则：新增支付渠道时，是否需要修改已有状态定义或转换逻辑？能否通过扩展实现？
• 状态显式化：所有状态是否使用枚举或常量定义？是否存在隐式状态（如数据库字段组合）？
• 避免状态爆炸：主状态数量是否控制在 5-8 个？是否使用了子状态或子状态机来管理细节？