Spring Data JPA Repositories, Transactions, and Fetching

Design the repository around the aggregate the application mutates, not around tables. Then place exactly one transaction boundary, one fetch plan, and one pagination strategy per use case. Every default Spring Data offers is correct for a sample application and wrong for a busy one unless you choose it deliberately.

When to use

• Repository interfaces, method names, JpaRepository inheritance, and a LazyInitializationException or N+1 log.
• The choice between join fetch, @EntityGraph, a fetch graph, and a projection, or a page count that explodes on deep offsets.
• Placing @Transactional, choosing propagation, auditing metadata, or picking JPA versus JdbcClient versus jOOQ per read and write.

When not to use

• Index design, dialect features, JSON columns, and server tuning belong to spring-boot-postgresql.
• Second-level cache, batch fetching, and statement inspection belong to spring-boot-hibernate.
• Reading pg_stat_statements and fixing a measured slow query belongs to spring-boot-query-optimization.
• Migration files belong to spring-boot-flyway; aggregate boundaries and repository placement belong to spring-boot-ddd and spring-boot-clean-architecture.

Ownership and sibling boundaries