Android原生开发：共享Entity模块是否为合理架构选择？

一、继续使用多模块独立数据类+映射的利弊 #

优点 #

• 构建隔离性强：修改某模块（如Firebase模块）时，仅会触发直接依赖它的模块（如领域层）重建，不会牵连大量无关模块，迭代阶段构建速度更快
• 模块职责清晰：每个模块的实体完全贴合自身场景，比如Firebase实体带专属注解、视图层实体只保留UI所需字段，不会出现为兼容多模块而冗余字段的情况
• 模块解耦彻底：各模块通过映射交互而非直接依赖实体，某模块实体变更不会影响其他不相关模块

缺点 #

• 代码冗余：存在大量结构完全一致的数据类，增加项目代码量
• 映射维护成本：需要编写并维护大量映射逻辑（手动转换或依赖MapStruct等工具），实体字段变更时需同步修改映射代码，容易出现遗漏或错误

二、采用共享Entity模块的利弊 #

优点 #

• 代码复用性高：避免重复定义相同结构的数据类，减少冗余代码
• 无映射成本：各模块直接依赖共享实体，无需额外转换逻辑，开发效率更高
• 实体一致性：所有模块使用同一实体结构，避免因映射错误导致的数据不一致问题

缺点 #

• 构建范围扩大：修改共享Entity模块时，所有依赖它的模块都会触发重建，项目模块越多，构建耗时越长
• 模块职责模糊：共享实体可能需要兼顾不同模块需求，比如为适配Firebase添加注解，导致领域层被迫依赖Firebase相关库，破坏领域层的纯净性
• 耦合风险提升：共享模块成为核心依赖，任何实体变更都需要考虑所有依赖模块的兼容性，迭代灵活性降低

三、决策建议 #

• 若项目模块数量少（核心业务模块少于10个）、实体变更频率低：优先选择共享Entity模块，减少冗余代码和映射成本，提升开发效率
• 若项目模块多、实体迭代频繁，或对构建速度要求较高：继续使用独立数据类+映射方案，以部分开发效率的牺牲，换取构建速度和模块解耦性
• 折中方案：拆分共享模块，将无框架依赖的纯业务核心实体（仅保留核心业务字段）放到共享模块，而带框架专属特性的实体（如Firebase注解实体、视图层精简实体）仍保留在各自模块，既复用核心代码，又避免全量构建和模块强耦合

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