паттерн Repository в Java и Kotlin зачем нужен если есть JPA

[gdgdgd]

Разбираю чужой код на Kotlin + Spring Boot, везде интерфейсы Repository поверх JpaRepository. Коллега говорит что это лишний слой абстракции, раз JpaRepository уже является репозиторием. Другой настаивает, что это must-have для тестируемости. Сам запутался. Зачем заворачивать JpaRepository в ещё один интерфейс, если Spring Data уже даёт всё из коробки?

[cohenst1]

Главная причина — развязка доменного слоя от инфраструктуры. Если ваш сервис напрямую зависит от JpaRepository, то в unit-тестах вам нужен либо H2, либо @DataJpaTest, либо mockito.mock(JpaRepository.class) с кучей заглушек. Если зависите от своего интерфейса UserRepository { fun findByEmail(email: String): User? }, то в тестах просто подставляете in-memory реализацию или простой mock — никакой Spring-магии.

[regexveteran]

Ещё практический кейс: у нас был проект, где начали с PostgreSQL через JPA, потом часть данных переехала в MongoDB. Потому что доменные сервисы зависели от своих Repository-интерфейсов, смена реализации заняла пару дней вместо недель переписывания. Если бы сервисы тащили JpaRepository напрямую — было бы больно.

[depechie]

Честно говоря, для маленьких CRUD-проектов это реально оверинжиниринг. Если у вас 10 сущностей, один источник данных и команда из 2 человек — дополнительный слой только добавляет бойлерплейт. Архитектурные паттерны надо применять под задачу, а не потому что так написано в книжке.

[rawgoblin]

В Kotlin есть приятный момент: можно объявить интерфейс Repository как sealed interface с несколькими реализациями — одна для JPA, одна для тестов. Выглядит чище, чем Java-аналог. Плюс корутины и Spring Data Kotlin extensions позволяют сделать suspend fun findByEmail(...) — и это реально удобно в reactive-стеке.

[penalty]

Важный нюанс: Repository-паттерн из DDD предполагает, что вы работаете с агрегатами, а не с отдельными таблицами. Если у вас findById возвращает Order со всеми OrderItems — это правильный агрегат. Если вы делаете отдельные репозитории для OrderItem — это уже просто DAO, а не Repository в смысле DDD. Разница принципиальная для понимания зачем это всё.