仓储接口按CRUD方法拆分的收益与过度设计疑问

潜在收益 #

• 单一职责更清晰：每个接口只对应一种CRUD操作，职责边界明确，不会出现一个接口混杂多种操作逻辑的情况，后续维护时找问题、改代码都更直接。
• 依赖更精准：调用方只需要注入自己实际需要的接口——比如只做数据查询的服务，就不用依赖包含增删改的完整仓储接口，减少不必要的耦合，也避免误调用无关方法。
• 扩展性更灵活：如果后续某类操作需要单独调整（比如GET方法加缓存、CREATE方法加参数校验），直接针对单个接口做实现或装饰即可，不会影响其他操作的逻辑。
• 测试更聚焦：测试单个操作接口时，不用考虑其他方法的干扰，测试用例更简洁，Mock也更简单——比如测查询逻辑，就不用Mock增删改的方法。

是否属于过度设计？ #

这得结合项目实际情况判断：

• 小型/需求稳定项目：大概率是过度设计。40个接口会直接增加代码量和维护成本，每个接口都要单独定义、实现，初期开发效率低；如果调用方大多需要完整的增删改查能力，拆分后反而要注入多个接口，徒增复杂度。
• 大型分布式/迭代频繁项目：拆分是合理的。比如不同微服务可能只需要某类操作的权限，拆分后能更精细化地做权限控制；或者后续不同操作可能适配不同的数据源（比如查询用读库、修改用写库），拆分后的接口更容易适配这种架构变化。

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