MVVM Clean架构中数据层DTO到领域对象的映射位置选型

在你的MVVM+整洁架构场景中，最优方案是在Repository层通过独立的Mapper类完成DTO到领域对象的映射，下面逐个拆解各方案的问题，并说明这个优化方案如何解决你的顾虑：

各方案问题分析 #

• 方案1（DataSource中映射）：完全违背整洁架构的依赖规则。DataSource的核心职责是从外部（API、数据库等）获取/存储原始数据，它不应该知晓领域层的对象——领域层是整个架构的核心，数据层应该依赖领域层，反过来会导致领域对象的变更牵连到数据源实现，彻底打乱分层边界。
• 方案2（两次映射）：纯粹增加冗余复杂度。多出来的中间层没有任何实际价值，反而要维护两套映射逻辑，后期迭代时的修改成本更高，完全没必要。
• 方案3（DTO继承接口实现映射）：把领域逻辑硬塞给了DTO。DTO本质是纯数据容器，不该承载转换逻辑；而且这样会让DTO和领域对象强绑定，领域对象的变更会直接影响DTO，违背了关注点分离的原则。

优化后的Repository映射方案 #

你最初的Repository映射方案的核心问题是把映射逻辑直接写在了Repository类中，导致Repository与DTO强耦合。解决办法是将映射逻辑抽成独立的Mapper类：

1. 定义独立的映射器类，比如UserDtoToDomainMapper，里面只负责UserDto到领域对象User的转换逻辑
2. Repository依赖这个映射器类，调用DataSource拿到DTO后，交给映射器完成转换，再返回领域对象

示例代码结构：

// 领域对象
data class User(val id: String, val name: String)

// DTO
data class UserDto(val userId: String, val userName: String)

// 独立映射器
class UserDtoToDomainMapper {
    fun map(dto: UserDto): User {
        return User(id = dto.userId, name = dto.userName)
    }
}

// Repository
class UserRepository(
    private val userDataSource: UserDataSource,
    private val mapper: UserDtoToDomainMapper
) {
    suspend fun getUser(): User {
        val dto = userDataSource.fetchUser()
        return mapper.map(dto)
    }
}

这种方案的优势：

• 符合分层规则：Repository的职责就是协调数据源+数据转换，映射逻辑抽离后，Repository只依赖映射器和领域对象，不直接与DTO耦合
• 解耦效果明显：当DTO结构变化时，只需要修改映射器的实现，Repository的核心逻辑（比如缓存策略、数据源选择）完全不需要改动
• 单一职责：映射器只负责数据转换，Repository只负责数据协调，各司其职，符合整洁代码原则

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