Clean Architecture中仅作为中间层的Use Case是否有必要保留？

你当前的场景不属于需要修改的代码坏味道，建议保留该Use Case，完全符合你提到的两种可容忍中间人的场景。

具体理由 #

符合「避免类间依赖」的设计目标 #

• 接口隔离原则适配：UserRepositoryInterface 对外暴露了getSingle、getAll两个能力，但你的ViewModel仅需要「获取所有用户」这一项业务能力，如果让ViewModel直接依赖仓储接口，会让视图层持有不需要的接口权限，也增加了不必要的耦合。用例层仅暴露get()这一个符合业务需求的方法，刚好约束了视图层的可调用范围。
• 依赖方向合规：整洁架构要求内层不依赖外层，用例层属于业务核心层，仓储属于接口适配器层，ViewModel作为外层的入口层，只应该依赖核心层的用例定义，不应该直接依赖外层的接口适配器。未来如果获取用户列表的逻辑需要拆分到多个仓储、或者新增本地缓存读取逻辑，只需要调整GetAllUsersUseCase的内部实现即可，ViewModel无需做任何改动。

属于架构设计主动创建的中间层 #

整洁架构的用例层本身就是设计层面约定的中间层，作用是封装单一的业务动作，和Proxy、Decorator这类设计模式主动创建中间层的逻辑一致。哪怕当前没有额外逻辑，也为未来的业务迭代预留了扩展点：

• 后续如果需求新增「过滤已禁用用户」「用户列表本地缓存优先」「权限校验」等逻辑，都可以直接在该UseCase中扩展，不需要调整上层ViewModel和下层仓储的代码
• 测试成本更低：ViewModel单测时仅需要MockGetAllUsers协议的get()方法即可，不需要Mock仓储的全量接口，测试用例更简洁。

什么情况下可以删除该UseCase？ #

如果你的项目是一次性的小型CRUD项目，可预期的周期内该业务逻辑不会有任何迭代，且整个项目不存在复杂的业务规则，那可以考虑省去该层减少冗余代码，否则保留的长期收益远高于多写几行代码的成本。

内容的提问来源于stack exchange，提问作者Bawenang Rukmoko Pardian Putra