Repository Pattern vs DAO Pattern in Spring Data

DAO and Repository are often used interchangeably, but they come from different design traditions with different implications. DAO is a J2EE pattern focused on abstracting database access — a UserDao wraps SQL operations for the users table, exposing findById, save, delete. It lives in the infrastructure layer and is allowed to know about database concepts like result sets and entity managers.

Repository comes from Domain-Driven Design. It models a collection of Aggregate Root objects. From the domain's perspective, the Repository looks like an in-memory collection — you add objects, query them, remove them, and persistence details are invisible. The interface lives in the domain layer and speaks domain language: findActiveOrdersForCustomer, not SELECT ... WHERE status = 'ACTIVE'.

Spring Data's JpaRepository has blurred this distinction. It's named Repository following DDD convention but behaves like a DAO — it generates SQL, manages EntityManager, and exposes Pageable and flush(). In a rigorous DDD application, you'd define a pure domain OrderRepository interface with zero Spring imports, and provide a JpaOrderRepository implementation in the infrastructure layer that delegates to Spring Data internally.

For most Spring Boot projects, using JpaRepository directly is pragmatic and correct. The domain/infrastructure split only earns its cost when the domain needs to be persistence-ignorant — complex business rules, hexagonal architecture, or realistic plans to switch databases. My default: start with JpaRepository, extract a domain-pure interface when the architecture demands it.