Android Kotlin结合Clean架构与DDD，用接口替代数据类作为领域模型是否可行？

两种实现路径的核心逻辑差异 #

• 常规Clean落地路径：三层各自维护独立的专属模型，通过Mapper完成跨层转换
  • 领域层：定义无任何框架依赖的纯数据类Movie，仅承载业务逻辑需要的字段和行为
  • 数据层：网络层定义带序列化注解的MovieDto、数据库层定义带ORM注解的MovieEntity，通过独立的Mapper组件完成到领域层Movie的转换
  • 表现层：定义承载UI状态的MovieUiModel，通过Mapper完成和领域模型的双向转换
  • 核心规则：所有依赖方向指向内层，领域层完全不感知外层的实现细节
• 省略转换的改造路径：定义领域接口IMovie封装属性契约，让网络层MovieDto直接实现该接口，Repository直接返回IMovie类型，跳过手动转换环节

接口直连方案的本质问题 #

很多开发者误以为只要用了接口就满足依赖倒置规则，实际上这个方案存在三个核心偏差：

1. 依赖方向的隐性反向渗透

   Clean架构的依赖规则核心不是“形式上用接口”，而是保证内层的定义完全不受外层实现的约束。当MovieDto实现IMovie接口时，Retrofit/Gson的序列化要求（比如必须保留无参构造、必须保留特定字段名的注解）会顺着接口直接绑定到领域契约上——一旦序列化规则调整，领域层定义的接口就得跟着改，相当于外层的约束反向渗透进了内层，完全违背了依赖规则的初衷。

2. 多数据源场景下的扩展性缺陷
   • 单一网络源的简单场景下，这个方案看似减少了代码量，但如果后续新增本地缓存、第三方SDK数据导入等数据源，对应的MovieEntity、SdkMovieModel都必须实现同一个IMovie接口，把不同数据源的实现约束全部绑定到领域契约上
   • 当领域模型需要新增业务计算属性（比如isRecentlyReleased、getFormattedReleaseDate）时，所有实现接口的外层类都要被迫同步调整实现，彻底颠倒了“外层适配内层需求”的架构关系
3. 测试隔离性被破坏
   常规路径下领域层的单元测试可以完全脱离Android框架、网络框架独立运行，测试启动速度极快。如果用接口绑定Dto，测试领域逻辑时很容易连带引入Gson注解处理、Retrofit依赖加载，拉长测试构建周期，甚至出现序列化相关的测试偶发失败。

两种实现路径的优劣势对比 #

• 短期开发成本
  • 独立模型+Mapper：初期需要编写模板化的转换代码，开发量相对更高
  • 接口直连：直接省略转换逻辑，初期代码量更少
• 长期维护成本
  • 独立模型+Mapper：各层模型独立迭代，字段调整、规则变更的影响范围被锁在单层内部，不会蔓延到业务逻辑层
  • 接口直连：任意外层的序列化规则、数据字段调整都会直接冲击领域层契约，修改成本随项目迭代指数级上升
• 依赖隔离度
  • 独立模型+Mapper：领域层零外部框架依赖，完全符合Clean架构的核心规则
  • 接口直连：仅形式上满足接口抽象要求，实际上领域契约和外层实现深度耦合
• 多场景适配能力
  • 独立模型+Mapper：新增数据源、新增UI展示逻辑时，只需补充对应层级的模型和Mapper，无需改动领域层代码
  • 接口直连：每新增一个数据源就必须让其模型实现领域接口，被迫适配所有契约约束
• 测试效率
  • 独立模型+Mapper：领域测试轻量化，无任何框架依赖，运行速度快
  • 接口直连：领域测试容易引入外层框架依赖，构建和运行速度下降

适配Clean架构与DDD的正确实践方向 #

1. 重新理解Mapper的价值
   Mapper组件的核心作用不是完成类型转换，而是作为外层和内层的隔离边界。可以借助MapStruct等代码生成工具自动生成Mapper的转换逻辑，把手写代码的成本降到最低，而不是为了省代码跳过隔离边界。
2. 严格限定领域模型的定位
   领域模型是用来封装业务规则的容器，只保留业务逻辑需要的字段和行为，完全剥离序列化、UI展示相关的冗余字段。不要把领域模型当成跨层通用的传值DTO，否则会把所有外部变更的压力全部转嫁到业务逻辑层。
3. 按需灵活调整严格度
   对简单的CRUD类项目，可以适度降低分层的严格度——哪怕所有层的模型字段完全1:1对齐，也要守住隔离底线：不让外层的实现类直接“变成”领域模型，哪怕写几行简单的转换代码，也要保证当外部规则变化时，修改范围不会扩散到核心业务逻辑实现里。

内容的提问来源于stack exchange，提问作者Armando Ávila Bueno