Android应用DDD架构下各层服务方法动词短语命名规范咨询

核心原则：分层职责匹配命名语义 #

在Android应用的DDD实践中，方法命名的核心是让名称直接体现该层的职责和操作特性，不用纠结绝对统一或完全差异化，关键是团队达成共识并保持一致性。

方案一：统一动词（如getXxx()） #

• 适用场景：当各层操作对上层是“黑盒”，上层只关心结果不关心实现时，统一用getXxx()是高效选择。比如Repository层对外屏蔽了网络/本地数据源差异，ViewModel只需调用getPlaylist()拿到结果，无需知道数据来源。
• 优点：代码简洁，上层调用心智负担低，不用记忆不同层的动词差异。
• 缺点：无法通过方法名快速区分底层操作类型，排查问题时需跳转至实现类查看细节。

方案二：分层差异化动词 #

• 推荐的动词映射（Android场景）：
  • ViewModel：getPlaylist() —— 对UI层而言，只需要“获取”数据展示，语义最直接
  • Repository：requestPlaylist() —— 仓储层是协调数据源的入口，“请求”体现它会调度底层服务
  • NetworkService：fetchPlaylist() —— 网络操作是从远程“拉取”数据，符合网络请求语义
  • DatabaseService：loadPlaylist() —— 本地数据库是从存储“加载”数据，对应本地读取操作
• 优点：方法名自带上下文信息，看名字就能知道操作所在层级和类型，调试维护更高效；符合DDD各层职责清晰的要求，仓储层的抽象不会掩盖底层服务特性。
• 缺点：需要团队统一动词字典，新人上手需熟悉规则，但形成共识后长期维护成本更低。

差异化命名是否过度复杂？ #

差异化命名并非“过度复杂化”，反而能提升代码可读性与可维护性——尤其是中大型Android项目中，团队成员快速定位问题时，方法名的语义可直接帮其判断是网络请求、本地缓存还是仓储层逻辑问题。

小型项目、团队成员少的情况下，统一用getXxx()完全没问题，优先快速开发；但长期迭代、多人协作的项目，更推荐分层差异化命名，能降低后期维护的沟通成本。

内容的提问来源于stack exchange，提问作者Peter G. Williams