多API顺序调用设计模式：支付商户入网场景优化咨询

针对你这种有严格执行顺序、失败后仅能重试当前步骤的商户入网流程，以下几种设计模式可以替代现有多布尔字段的状态管理方案，让代码更简洁、易维护：

1. 状态模式（State Pattern） #

这是最贴合你场景的模式，核心是把每个步骤的行为和状态判断逻辑封装成独立的状态类，避免大量if-else判断多个布尔字段：

• 定义一个基础状态接口，比如MerchantOnboardingStep，包含execute(Context context)方法（执行当前步骤API）和getNextStep()方法（返回下一个步骤）。
• 为每个入网步骤实现对应的状态类：UserCreationStep、BusinessProfileStep、PaymentProfileStep、WebhookRegistrationStep。每个类里只负责当前步骤的API调用逻辑，成功后返回下一个步骤，失败则保持当前步骤。
• 用一个上下文类OnboardingContext保存当前步骤、商户ID、API凭证等核心数据，重试时直接调用当前步骤的execute()方法即可。

示例伪代码：

OnboardingContext context = loadContextFromStorage(merchantId);
if (context.getCurrentStep() == null) {
    context.setCurrentStep(new UserCreationStep());
}
try {
    MerchantOnboardingStep nextStep = context.getCurrentStep().execute(context);
    context.setCurrentStep(nextStep);
    saveContextToStorage(context);
} catch (ApiException e) {
    // 失败不切换步骤，直接等待重试
    log.error("Step failed: {}", context.getCurrentStep().getName(), e);
}

优势：新增步骤只需添加新的状态类，符合开闭原则；状态切换逻辑内聚，不用在业务代码里写一堆状态判断。

2. 备忘录模式（Memento Pattern） #

如果需要持久化流程状态，备忘录模式可以替代多个布尔字段的存储：

• 不用保存四个布尔值，而是保存一个当前步骤标识（比如枚举OnboardingStage：USER_CREATION、BUSINESS_PROFILE、PAYMENT_PROFILE、WEBHOOK_REGISTRATION）和流程关键数据（如商户ID）。
• 把这些数据封装成一个备忘录对象，序列化后存储到数据库或缓存。重试时从备忘录恢复当前步骤，直接执行对应API调用。

优势：状态存储更简洁，只用一个字段标识当前阶段，避免多个布尔字段的组合判断。

3. 简化版Saga模式 #

如果你的流程涉及多服务交互（比如后续还要对接内部CRM、财务系统），简化版Saga模式也适用：

• 用一个协调器来管理流程，记录每个步骤的执行状态（成功/失败/未执行）。
• 协调器根据当前步骤的状态，决定是继续执行下一步，还是重试失败的步骤。状态记录只用一个步骤序号或阶段标识即可，不用维护多个布尔字段。

对比现有方案的优化点 #

现有方案维护四个布尔字段，当后续新增入网步骤时，字段会持续增加，状态判断逻辑会变得臃肿（比如要写userCreated && !businessProfileCreated来确定执行第二步）。而用上述模式后：

• 状态判断逻辑内聚到对应类中，业务代码更干净
• 新增步骤只需扩展类或枚举，无需修改原有状态判断逻辑
• 状态存储更简洁，减少冗余字段

内容的提问来源于stack exchange，提问作者Aquib Jawed