Spring Boot中通过Spring Repository封装数据库对象读取的架构方案咨询

• 优先收口到UserService领域服务，这是最符合领域驱动设计（DDD）规范的实现方案。你可以在UserService中封装统一的查询方法：

@Service
public class UserService {
    private final UserRepository userRepository;

    @Transactional(readOnly = true)
    public User getValidUserById(long userId) {
        return userRepository.findById(userId)
            .orElseThrow(() -> new EntityNotFoundException(String.format("User not found [id: %d]", userId)));
    }
}

后续所有业务Service需要操作用户时，直接注入UserService调用该方法即可。这种方案的优势在于后续如果要新增用户查询的前置校验（比如校验用户状态是否禁用）、关联查询（比如附带查询用户权限信息）、性能优化（比如加缓存），都只需要修改一处逻辑，不会出现散落在各业务类中的重复修改。

• 禁止业务层直接操作UserRepository做带业务逻辑的查询。Repository层仅应该封装最基础的CRUD能力，业务规则、异常封装、参数校验都应该收束到领域服务层，避免不同开发人员写出逻辑不一致的查询代码。

如果你的场景不需要太重的领域服务封装，也可以根据业务复杂度选择更轻量的方案：

• 封装通用基础Repository
  如果多个实体都有「按ID查询不存在则抛异常」的通用需求，可以封装公共的基础Repository接口，所有业务Repository继承即可：

public interface BaseRepository<T, ID> extends JpaRepository<T, ID> {
    default T getByIdOrThrow(ID id) {
        return findById(id)
            .orElseThrow(() -> new EntityNotFoundException(String.format("Entity not found [id: %s]", id)));
    }
}

// UserRepository直接继承即可
public interface UserRepository extends BaseRepository<User, Long> {
}

业务代码直接调用userRepository.getByIdOrThrow(userId)即可，适合逻辑简单、不需要额外用户校验的场景。

• 借助Spring参数解析器/AOP自动注入用户
  如果是Web项目，大量Controller/Service方法都需要根据请求携带的userId查询用户，可以自定义注解配合Spring MVC参数解析器，在方法执行前自动查询并注入User对象：

// 方法中直接拿到User对象，无需手动查询
@Transactional
public void someMethodInServiceA(@FetchUser Long userId, User user) {
    // 直接执行业务逻辑
}

这种方案可以最大程度减少重复代码，适合高频查询用户的业务场景。

• 增加缓存层优化查询性能
  如果用户查询的QPS较高，可以在统一的查询方法上加Spring Cache注解，减少数据库访问压力：

@Cacheable(value = "userCache", key = "#userId")
@Transactional(readOnly = true)
public User getValidUserById(long userId) {
    // 原有查询逻辑
}

注意需要配套处理用户信息更新时的缓存失效逻辑，避免数据不一致。

• 业务简单、仅需要统一异常逻辑的场景，选基础Repository封装方案
• 后续用户查询逻辑可能扩展的场景，选UserService收口方案
• 大量方法都需要查询用户的Web项目，选参数解析器/AOP自动注入方案

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