Flutter Clean架构中fromJson/toJson应放在业务层还是数据层？

核心原则 #

Clean架构的核心就是让业务层（领域层）彻底脱离外部依赖，业务层的Entity只负责承载业务逻辑和核心数据，绝对不能掺和数据序列化这种和具体数据源绑定的细节——这类细节属于数据层的职责范畴。

具体实现方式 #

• 业务层Entity：只保留业务相关的属性和方法，完全不碰fromJson/toJson。比如：

  // 业务层UserEntity
  data class UserEntity(
      val userId: String,
      val nickname: String,
      val contactEmail: String
      // 这里只放业务逻辑方法，比如checkEmailValid()
  )
  

• 数据层Model：作为和外部数据源（API、数据库）交互的专属载体，负责实现fromJson（把接口返回的JSON转成Model）、toJson（把Model转成JSON用于接口请求），同时提供和业务层Entity互相转换的方法。比如：

  // 数据层UserModel（继承自Entity的话，可根据实际情况调整结构）
  data class UserModel(
      val id: String,
      val nickname: String,
      val email: String,
      val apiOnlyField: String // 接口返回但业务层不需要的字段
  ) {
      // 从JSON反序列化为Model
      fun fromJson(jsonStr: String): UserModel {
          // 这里写具体的序列化逻辑，比如用Moshi/Gson解析
      }
  
      // 把Model序列化为JSON字符串
      fun toJson(): String {
          // 具体序列化逻辑实现
      }
  
      // 转换为业务层需要的Entity
      fun mapToEntity(): UserEntity {
          return UserEntity(
              userId = this.id,
              nickname = this.nickname,
              contactEmail = this.email
          )
      }
  }
  

• 数据层Repository：在和数据源交互时，先把JSON转成数据层Model，再转换成业务层Entity返回给上层；当需要提交数据时，接收业务层传来的Entity，转成Model后序列化为JSON发送给数据源。

这么做的原因 #

• 业务层彻底解耦：如果后续接口JSON结构变动，只需要修改数据层的Model和转换逻辑，业务层的代码完全不用动，避免牵一发而动全身。
• 符合Clean架构依赖规则：依赖只能从外层（数据层）指向内层（业务层），数据层可以依赖业务层的Entity，但业务层绝对不能依赖数据层的序列化工具或逻辑，否则就破坏了架构的独立性。

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