Flutter Clean Architecture中Failure类直接调用Firebase Crashlytics是否合规？

直接在UnknownFailure类中调用FirebaseCrashlytics实例不符合Clean Architecture的核心原则，原因如下：

• Clean Architecture要求Domain层（Failure类属于这一层）必须独立于外部框架、第三方服务或具体实现细节。现在的写法让Domain层直接依赖Firebase这个外部库，破坏了层间依赖规则（应该是外层依赖内层，而非内层依赖外层）。
• 这种耦合会导致后续难以替换上报服务（比如换成Bugly），也无法在单元测试中隔离Firebase的影响，降低了代码的可测试性和灵活性。

优化方案：依赖倒置+抽象接口 #

我们可以通过定义抽象上报接口，将上报逻辑从Domain层剥离到外层，符合Clean Architecture的依赖规则：

1. 在Domain层定义抽象上报接口

abstract class ExceptionReporter {
  void reportUnknownError(dynamic exception, StackTrace stackTrace);
}

2. 在外层（如Infrastructure层）实现具体的上报逻辑

class FirebaseExceptionReporter implements ExceptionReporter {
  @override
  void reportUnknownError(dynamic exception, StackTrace stackTrace) {
    FirebaseCrashlytics.instance.recordError(exception, stackTrace, fatal: true);
  }
}

3. 修改UnknownFailure类，移除上报逻辑

class UnknownFailure extends Failure {}

4. 在Service层注入ExceptionReporter并调用上报

// 通过构造函数注入ExceptionReporter
class UpdateService {
  final InAppUpdateRepository inAppUpdateRepository;
  final ExceptionReporter exceptionReporter;

  UpdateService({
    required this.inAppUpdateRepository,
    required this.exceptionReporter,
  });

  AsyncResult<bool> checkForUpdate() async {
    try {
      var result = await inAppUpdateRepository.checkForUpdate();
      return Result.success(result);
    } on IsarDBException {
      return Result.error(LocalDBFailure());
    } catch (exception, stack) {
      exceptionReporter.reportUnknownError(exception, stack);
      return Result.error(UnknownFailure());
    }
  }
}

方案优势 #

• 符合Clean Architecture的依赖倒置原则：Domain层只依赖抽象接口，不依赖任何外部实现。
• 灵活性更高：后续更换上报服务时，只需新增一个ExceptionReporter的实现类，无需修改Domain层和Service层的核心逻辑。
• 可测试性提升：单元测试时可以传入Mock的ExceptionReporter，避免调用真实的Firebase服务。

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