Android多模块架构中，Domain层与Data层依赖方向哪种更优？

部分Android多模块架构示例显示Domain层依赖于Data层，另一些则相反。Android开发者官网指出：

Domain层是位于UI层与Data层之间的可选层级。
同时官网展示的图示中，Domain层依赖于Data层。

而另一篇技术文章提到：

Domain层是洋葱架构的最核心部分（不依赖其他层级），包含Entities、用例及Repository接口。用例整合来自一个或多个Repository接口的数据。
最常见的错误之一是让应用由Data层/特定数据系统驱动。
Domain层不依赖Data层。
该文章也配有对应图示。

因此想请教，在Android多模块架构中哪种依赖方式更优，原因是什么？

两种依赖方式的核心差异与适用场景 #

1. Domain层依赖Data层（Android官网推荐的传统分层） #

• 核心逻辑：Domain层作为UI和Data的中间层，直接调用Data层的具体实现来获取数据，处理业务逻辑后返回给UI层。
• 优势：
  • 架构简单直观，上手成本低，适合小型项目或快速迭代的业务场景。
  • 无需额外的接口抽象和依赖注入，代码量更少，初期开发效率高。
• 劣势：
  • Domain层与Data层耦合度高，若Data层实现（比如从Room切换到Firebase）变更，Domain层代码需同步修改。
  • 业务逻辑易被Data层的具体实现绑架，比如为适配数据库特性调整业务规则，违背"业务驱动"原则。

2. Domain层不依赖Data层（洋葱架构/清洁架构思路） #

• 核心逻辑：Domain层定义Repository的抽象接口，Data层实现这些接口；Domain层仅关注业务规则，完全不关心数据的来源与存储方式，通过依赖注入将Data层实现注入到Domain层使用。
• 优势：
  • 业务逻辑完全独立，不受Data层变化影响，切换数据源时仅需替换Data层实现类，Domain层和UI层无需改动。
  • 符合依赖倒置原则，高层模块（Domain）不依赖低层模块（Data），两者均依赖抽象，架构扩展性与可维护性更强，适合中大型、长期迭代的项目。
  • 业务逻辑更纯粹，不会被数据存储细节干扰，更容易保证业务规则的一致性。
• 劣势：
  • 需要额外定义抽象接口并配置依赖注入，初期架构复杂度更高，对团队技术能力有一定要求。
  • 小型项目中会显得过度设计，增加不必要的开发成本。

总结：按需选择，无绝对最优 #

• 若为小型项目、快速验证需求：优先选择Domain依赖Data的方式，快速落地，避免过度设计。
• 若为中大型项目、长期维护迭代：优先选择Domain不依赖Data的方式，保障架构灵活性与业务逻辑独立性，降低后续维护成本。

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