为什么 Clean Architectures 通常会在 Repository 和 DataSoruce 之间拆分实现？

问：

在大多数演示 Clean Architecture 的示例中，存储库的实现和实际接口（与包含其数据的存储库通信）在依赖关系中是分开的，如下面的代码所示。

// Retrofit
interface MyApi {
   @GET("somePath")
   fun getSome() : SomeResponse
}

// Room
@Dao
interface MyDao {
   @Query("select * from mytable")
   fun getSome() : List<SomeEntity>
}

// 1. This is how most examples describe the configuration of a repository.
interface RemoteDataSource {
   fun getSome() : SomeResponse
}
interface LocalDataSource {
   fun getSome() : List<SomeEntity>
}

// instance inject by hilt
class RemoteDataSourceImpl @Inject constructor(private val api : MyApi) : RemoteDataSource {
    override fun getSome() = api.getSome()
}

// instance inject by hilt
class LocalDataSourceImpl @Inject constructor(private val dao : MyDao) : LocalDataSource {
    override fun getSome() = dao.getSome()
}

// instance inject by hilt
class MyRepositoryImpl @Inject (private val remote : RemoteDataSource, private val local : LocalDataSource) : MyRepository {
   override mySomeGetFunction() {
      return MySomeEntity(entity1 = remote.getSome().data, entity2 = local.getSome().data)
   }
}


// 2. why not inline???
// instance inject by hilt
class MyRepositoryImpl @Inject (private val api : MyApi, private val dao : MyDao) : MyRepository {
   override mySomeGetFunction() {
      return MySomeEntity(entity1 = api.getSome().data, entity2 = dao.getSome().data)
   }
}

它们已经是接口了。尽管它们是弱依赖类型，其注入可以根据构建风格随意交换，但许多示例再次将它们包装为 DataSource，并在其实现中简单地绕过它们。

这样做有什么前期原因吗？我试图找到很多参考资料，但我没有看到任何关于 Repository 和 DataSource 的信息。