Clean Architecture中Firebase事件追踪代码的架构布局疑问

核心原则：领域层（含UseCase）需独立于外部依赖 #

Firebase属于第三方服务框架，直接将其代码写入UseCase会破坏Clean Architecture的依赖规则——领域层作为核心，不应依赖任何外部基础设施（包括Firebase、数据库等），否则后续更换追踪服务时，会被迫修改领域层代码，违背开闭原则。

正确的分层实现方式 #

• 领域层定义抽象接口：创建一个通用的事件追踪抽象，比如：

  interface EventTracker {
      fun trackEvent(eventName: String, params: Map<String, Any>)
  }
  

  这里的参数用领域内通用的结构，不要绑定Firebase的特定格式。
• 基础设施层实现接口：在基础设施层编写FirebaseEventTracker实现上述接口，内部调用Firebase SDK完成实际追踪：

  class FirebaseEventTracker : EventTracker {
      override fun trackEvent(eventName: String, params: Map<String, Any>) {
          FirebaseAnalytics.getInstance(context).logEvent(eventName, params.toBundle())
      }
  }
  

• 依赖注入解耦：通过依赖注入框架（如Hilt、Dagger）将FirebaseEventTracker实例注入到需要的地方。
• 业务相关追踪放在UseCase：如果是和业务流程绑定的事件（比如用户完成订单、提交表单），在UseCase中调用EventTracker接口方法，保证业务逻辑和追踪逻辑的一致性，避免遗漏。
• UI交互追踪可放在Presenter：如果是纯UI交互事件（比如按钮点击、页面跳转），可以直接在Presenter中调用EventTracker，这类事件和业务逻辑关联较弱。

总结 #

不要直接把Firebase代码移到UseCase，但可以通过抽象接口+依赖注入的方式，让UseCase间接调用追踪逻辑，既符合Clean Architecture的分层规则，又能保证追踪逻辑的可维护性。

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