我的知识库

Appearance

🎯 重构完成总结 ​

✅ 修改完成 ​

已成功将所有 Saga 类的自注入模式重构为独立的事务服务，完全符合 DDD 和 SOLID 原则。

📊 修改前存在的隐患问题 ​

1. 循环依赖风险（致命问题） ​

java
// 旧代码示例
@Component
public class ActivityCancellationSaga {
    @Resource
    private ActivityCancellationSaga self;  // ❌ 自注入自己
    
    public SagaResult execute(Command command) {
        ActivityAggregate activity = self.executeStep1_CancelActivity(command);  
        // ⚠️ 依赖 Spring AOP 代理，但容易触发循环依赖
    }
}

问题：

  • Spring Boot 3.x 默认禁止循环依赖（spring.main.allow-circular-references=false）

  • 启动时抛出 BeanCreationException：The dependencies of some of the beans in the application context form a cycle

  • 强制开启循环依赖会导致其他 Bean 初始化顺序混乱

2. 事务失效风险（严重问题） ​

java
// 旧代码示例
@Transactional(rollbackFor = Exception.class)
protected void compensateStep1_RestoreActivity(SagaStep step) {
    // 事务逻辑
}

public void compensate() {
    // ❌ 通过 this 调用，Spring AOP 代理不起作用
    this.compensateStep1_RestoreActivity(step);  
    // ⚠️ @Transactional 完全失效！
}

问题：

  • 使用 this.method() 调用事务方法时，绕过了 Spring AOP 代理

  • 事务注解 @Transactional 完全失效，数据一致性无法保证

  • 补偿逻辑失败时可能导致数据不一致

3. 违反 SOLID 原则（设计问题） ​

违反单一职责原则（SRP）：

  • Saga 类既负责流程编排，又包含事务操作

  • 代码耦合度高，难以单独测试

违反依赖倒置原则（DIP）：

  • Saga 依赖自己的实现类（具体类），而非接口

  • 无法通过依赖注入实现灵活扩展

4. 代码可维护性差（工程问题） ​

  • 自注入的意图不明确，新成员难以理解

  • 事务边界模糊，容易引入新的 bug

  • 补偿逻辑和业务逻辑混在一起

✨ 修改后解决的问题 ​

1. 彻底解决循环依赖 ​

java
// 新代码示例
@Service
public class ActivityTransactionService {  // ✅ 独立的事务服务
    @Transactional(rollbackFor = Exception.class)
    public ActivityAggregate cancelActivity(Command command, String sagaId) {
        // 事务逻辑
    }
}

@Component
public class ActivityCancellationSaga {
    @Resource
    private ActivityTransactionService activityTransactionService;  // ✅ 注入事务服务
    
    public SagaResult execute(Command command) {
        ActivityAggregate activity = executeStep1_CancelActivity(command);
    }
    
    protected ActivityAggregate executeStep1_CancelActivity(Command command) {
        // ✅ 调用事务服务，Spring AOP 代理生效
        return activityTransactionService.cancelActivity(command, sagaId);
    }
}

效果：

  • ✅ 完全消除循环依赖，Spring Boot 3.x 可正常启动

  • ✅ 不需要配置 allow-circular-references=true

  • ✅ Bean 初始化顺序清晰，启动速度更快

2. 事务100%生效 ​

java
// 新代码示例
@Service
public class ActivityTransactionService {
    @Transactional(rollbackFor = Exception.class)  // ✅ 事务注解生效
    public ActivityAggregate cancelActivity(Command command, String sagaId) {
        // 业务逻辑
        activity.cancelActivity(command.getReason());
        activityRepository.update(activity);
        domainEventPublisher.publishAll(activity.getDomainEvents());
        // ✅ 事务保证原子性
    }
}

效果：

  • ✅ 事务注解 @Transactional 100% 生效

  • ✅ Spring AOP 代理正常工作

  • ✅ 数据一致性得到保证

  • ✅ 回滚机制正常工作

3. 完全符合 SOLID 原则 ​

单一职责原则（SRP）：

  • Saga 类：只负责流程编排（Step 1 → Step 2 → Step 3）

  • 事务服务：只负责事务操作（增删改查 + 事件发布）

  • 职责清晰，代码简洁

依赖倒置原则（DIP）：

  • Saga 依赖事务服务接口（未来可抽象为接口）

  • 事务服务依赖仓储接口（IActivityAggregateRepository）

  • 依赖关系清晰，易于扩展和测试

开闭原则（OCP）：

  • 新增业务逻辑：在事务服务中添加新方法

  • 新增 Saga 步骤：调用事务服务即可

  • 无需修改现有代码

4. 代码可维护性大幅提升 ​

  • ✅ 事务边界清晰：所有事务逻辑都在 xxxTransactionService 中

  • ✅ 代码结构清晰：Saga 只负责编排，服务负责执行

  • ✅ 易于测试：可单独测试事务服务和 Saga 逻辑

  • ✅ 易于理解：新成员一眼就能看懂架构

📁 涉及的文件变更 ​

新增文件（4个事务服务）： ​

  1. ActivityTransactionService.java - 活动事务服务（取消、恢复、完成）

  2. ActivityRegistrationTransactionService.java - 活动报名事务服务

  3. ActivityQuitTransactionService.java - 活动退出事务服务

  4. RefundApplicationTransactionService.java - 退款申请事务服务

修改文件（5个 Saga 类）： ​

  1. ActivityCancellationSaga.java - 移除 self 注入，改用 activityTransactionService

  2. ActivityRegistrationSaga.java - 移除 self 注入，改用 registrationTransactionService

  3. ActivityQuitSaga.java - 移除 self 注入，改用 quitTransactionService

  4. PartialRefundSaga.java - 移除 self 注入，改用 refundTransactionService

  5. ActivityCompletionSaga.java - 移除 self 注入，改用 activityTransactionService

🎉 重构优势总结 ​

维度修改前修改后
循环依赖❌ 触发 BeanCreationException✅ 完全消除
事务生效❌ 自调用失效✅ 100% 生效
SOLID 原则❌ 违反 SRP/DIP✅ 完全符合
代码可读性⚠️ 自注入意图不明✅ 结构清晰
可测试性⚠️ 难以隔离测试✅ 易于单元测试
可扩展性⚠️ 紧耦合✅ 松耦合
启动成功率❌ Spring Boot 3.x 启动失败✅ 正常启动

PS ​

SOLID 原则 ​

SOLID 是面向对象设计（OOD）的五大原则，由 Robert C. Martin 提出，分别是：

  • Single Responsibility Principle（单一职责原则，SRP）
  • Open/Closed Principle（开闭原则，OCP）
  • Liskov Substitution Principle（里氏替换原则，LSP）
  • Interface Segregation Principle（接口隔离原则，ISP）
  • Dependency Inversion Principle（依赖倒置原则，DIP）

你问的是“违反 SRP 和 DIP 是什么”，下面我详细解释这两个原则的含义，以及违反它们会带来什么问题和典型表现，并配上代码示例。

1. Single Responsibility Principle（SRP）——单一职责原则 ​

定义：一个类应该只有一个变更的原因（A class should have only one reason to change）。

违反 SRP 的表现：

  • 一个类承担了多个职责（例如：业务逻辑 + 数据持久化 + 日志记录 + 邮件发送等）。
  • 当某个职责需要修改时，会意外影响其他职责，导致代码脆弱、难以测试和维护。

违反 SRP 的坏例子（Java 示例）：

java
public class OrderService {
    // 职责1：处理订单业务逻辑
    public void createOrder(Order order) {
        // 业务校验、计算价格等
    }

    // 职责2：持久化到数据库
    public void saveOrderToDatabase(Order order) {
        // JDBC 或 JPA 操作保存订单
    }

    // 职责3：发送通知邮件
    public void sendOrderConfirmationEmail(Order order) {
        // 调用邮件服务发送邮件
    }

    // 职责4：记录日志
    public void logOrderCreation(Order order) {
        // 写日志文件或日志系统
    }
}

问题：

  • 如果数据库 schema 变了，需要改 saveOrderToDatabase，可能会不小心影响到业务逻辑。
  • 如果邮件服务提供商换了，需要改邮件发送逻辑，可能引入 bug 到订单创建的核心流程。
  • 测试困难：测试业务逻辑时不得不 mock 数据库和邮件服务。

符合 SRP 的改进：

java
public class OrderService {                     // 只负责业务逻辑
    private final OrderRepository repository;
    private final EmailService emailService;
    private final LoggingService loggingService;

    public void createOrder(Order order) {
        // 业务逻辑
        repository.save(order);
        emailService.sendConfirmation(order);
        loggingService.log(order);
    }
}

// 各自独立的类
public class OrderRepository { ... }           // 只负责持久化
public class EmailService { ... }              // 只负责发邮件
public class LoggingService { ... }            // 只负责日志

2. Dependency Inversion Principle（DIP）——依赖倒置原则 ​

定义：

  • 高层模块不应该依赖低层模块，二者都应该依赖抽象（Abstractions should not depend on details. Details should depend on abstractions）。
  • 抽象不应该依赖于细节，细节应该依赖于抽象。

违反 DIP 的表现：

  • 高层业务类直接依赖具体的底层实现类（而不是接口或抽象）。
  • 导致代码耦合度高、难以替换实现、难以单元测试（需要依赖真实实现）。

违反 DIP 的坏例子：

java
public class OrderService {                     // 高层模块
    private MySqlOrderRepository repository = new MySqlOrderRepository();  // 直接依赖具体实现

    public void createOrder(Order order) {
        repository.save(order);                // 紧耦合 MySQL
    }
}

public class MySqlOrderRepository {            // 低层具体实现
    public void save(Order order) {
        // 使用 MySQL 保存
    }
}

问题：

  • 如果想换成 PostgreSQL 或 MongoDB，必须修改 OrderService 的代码（违反开闭原则）。
  • 单元测试 OrderService 时，无法轻易 mock 数据库，必须启动真实的 MySQL。
  • 高层业务逻辑被底层数据库技术细节“污染”。

符合 DIP 的改进（依赖注入 + 抽象）：

java
public interface OrderRepository {             // 抽象（接口）
    void save(Order order);
}

public class MySqlOrderRepository implements OrderRepository { ... }
public class PostgresOrderRepository implements OrderRepository { ... }

public class OrderService {                     // 高层模块依赖抽象
    private final OrderRepository repository;  // 依赖接口，而不是具体类

    public OrderService(OrderRepository repository) {  // 通过构造器注入
        this.repository = repository;
    }

    public void createOrder(Order order) {
        repository.save(order);
    }
}

好处：

  • 可以轻松替换数据库实现（只需换注入的 Bean）。
  • 单元测试时注入 mock 的 OrderRepository。
  • 高层模块不再关心底层细节。

总结对比 ​

原则违反时的典型症状后果修复核心思路
SRP一个类干了很多不相关的事修改一处影响多处、测试难、维护成本高将不同职责拆分成独立类
DIP高层直接 new 或依赖具体实现类紧耦合、难以替换实现、难以 mock 测试高层依赖抽象，细节实现依赖抽象，通过 DI 注入

遵守 SRP 和 DIP 是构建可维护、可测试、可扩展系统的基石，尤其在大型项目和使用 Spring 等依赖注入框架时几乎是标配。

违反依赖倒置原则的详解 ​

什么是依赖倒置原则（DIP）？ ​

核心思想：高层模块不应该依赖低层模块，两者都应该依赖抽象（接口）。

你的代码问题 ​

java
@Service
public class PaymentCallbackApplicationService {  // App 层（高层）
    
    @Resource
    private IPaymentPort paymentPort;  // ✅ 依赖接口（正确）
    
    @Resource
    private PaymentAdapter paymentAdapter;  // ❌ 依赖实现类（错误）
}

架构层级：

App 层（高层）
  ↓ 应该依赖
Domain 层（接口定义）
  ↑ 被实现
Infrastructure 层（低层）

问题分析：

  1. PaymentCallbackApplicationService 在 App 层（高层）
  2. PaymentAdapter 在 Infrastructure 层（低层）
  3. 直接依赖 = App 层直接依赖 Infrastructure 层 ❌

导致的问题：

  • ❌ 耦合度高：App 层知道具体实现细节

  • ❌ 难以测试：无法 Mock PaymentAdapter

  • ❌ 难以替换：如果换支付宝，需要改 App 层代码

  • ❌ 启动失败：PaymentAdapter 依赖微信 SDK，微信 SDK 的 Bean 不存在时，整个应用启动失败

正确的做法 ​

java
@Service
public class PaymentCallbackApplicationService {
    
    @Resource
    private IPaymentPort paymentPort;  // ✅ 只依赖接口
    
    // ❌ 删除这行
    // @Resource
    // private PaymentAdapter paymentAdapter;
    
    @Override
    @Transactional(rollbackFor = Exception.class)
    public boolean handlePaymentCallback(String orderId, String transactionId, OrderStatus status) {
        String idempotentKey = IDEMPOTENT_KEY_PREFIX + "pay:" + orderId;
        
        if (!tryAcquireIdempotentLock(idempotentKey)) {
            log.info("[支付回调] 重复回调，已忽略 - 订单ID: {}", orderId);
            return true;
        }
        
        try {
            log.info("[支付回调] 开始处理支付回调 - 订单ID: {}, 微信订单号: {}, 状态: {}", 
                    orderId, transactionId, status);
            
            // ✅ 直接使用接口（不管底层是 PaymentAdapter 还是 EmptyPaymentAdapter）
            // 但问题是：IPaymentPort 接口没有 updateOrderStatus 方法！
            // paymentPort.updateOrderStatus(orderId, status);  
            
            // 这就是为什么原作者要直接注入 PaymentAdapter
            // 因为 updateOrderStatus 不是端口接口的一部分
            
            // ... Saga 逻辑
            
            return true;
        } catch (Exception e) {
            log.error("[支付回调] 支付回调处理失败 - 订单ID: {}", orderId, e);
            releaseIdempotentLock(idempotentKey);
            throw e;
        }
    }
}

Powered by VitePress

© 2026 skeeter