Repositories

Репозиторий как граница доступа к данным

Если сервису нужно сохранить клиента или найти его по идентификатору, ему не обязательно знать, как создаётся SQL и как результат запроса превращается в объект. Эту ответственность можно вынести в repository — отдельный интерфейс доступа к данным.

interface CustomerRepository extends CrudRepository<Customer, Long> {
}

@Service
class CustomerService {
    private final CustomerRepository repository;

    CustomerService(CustomerRepository repository) {
        this.repository = repository;
    }

    Customer find(long id) {
        return repository.findById(id).orElseThrow();
    }
}

Мы объявили только интерфейс. Реализацию типичных операций создаёт Spring Data JDBC, а сам репозиторий становится обычным Spring bean и может внедряться через конструктор. Первый generic-параметр указывает тип сущности, второй — тип её идентификатора.

Что должно оставаться за пределами репозитория

Repository отвечает за доступ к данным, а не за бизнес-сценарий целиком. Например, правило «нельзя деактивировать последнего администратора» относится к логике приложения, поэтому его место скорее в сервисе. Репозиторий может предоставить нужные данные или операцию записи, но не должен становиться контейнером для всей бизнес-логики.