是否必须始终使用用例？项目中用例设计困惑咨询

• 优先保留用例的分层价值：别着急直接跳过用例层调用Repository。哪怕现在只是一行转发代码，用例层是领域逻辑的"收口"——以后如果要加校验、日志、权限检查或者扩展业务规则，直接在这个用例里加就行，不用去改上层调用逻辑。比如现在的GetUserByIdUseCase只是转调Repository，哪天要加"仅管理员能查看用户详情"的规则，直接在这个用例里加判断，上层服务层完全不用动。

• 区分"业务用例"和"基础操作用例"：像RegisterUserUseCase这种涉及多Repository交互、业务规则的，肯定是核心用例；而那些单Repository转发的，可以归为基础操作用例，统一做轻量化处理——比如用通用模板或者抽象基类来减少重复代码，不用每个都写单独的类。这样既保留了分层，又避免冗余。

• 团队约定大于教条：如果团队已经习惯了用例层的统一模式，哪怕是转发代码，也尽量保持一致，减少认知成本。要是团队更看重精简，那可以只在有业务逻辑时创建用例，但要提前约定好边界——比如什么情况算"有价值"，避免后续出现标准不统一的混乱。

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