What is the Repository Pattern?
Learn the Repository pattern — a collection-like interface that decouples domain logic from persistence — with a Java example and Q&A.
Expected Interview Answer
The Repository pattern is a design pattern that mediates between the domain/business logic and the data mapping layer, exposing a collection-like interface (add, remove, findById, findAll) so callers can work with domain objects without knowing how they are persisted.
A repository sits in front of the actual data access code (ORM calls, SQL, an external API) and presents an interface that looks like an in-memory collection of objects. Business logic depends only on the repository interface, never on the database or ORM directly, which decouples domain logic from persistence technology. This makes it possible to swap PostgreSQL for MongoDB, or a real database for an in-memory fake in tests, without touching business logic. Repositories are typically defined per aggregate root in domain-driven design, and each repository hides query construction, caching, and mapping between persistence models and domain models behind a small, focused contract.
- Decouples business logic from persistence technology
- Enables fast unit tests via in-memory fake repositories
- Centralizes query logic for a given aggregate in one place
- Supports swapping data stores without touching domain code
AI Mentor Explanation
A team’s chief selector does not personally dig through decades of scorecards and fitness reports; they hand a request like "find me all fast bowlers under 25" to the analytics desk, which knows exactly where and how that data is stored. The selector only ever talks to the analytics desk’s simple interface, never to the raw filing system underneath. That is the Repository pattern: business logic (selection decisions) talks to a collection-like interface, while the repository hides how records are actually stored and retrieved.
Step-by-Step Explanation
Step 1
Define a repository interface
Declare collection-like operations (add, remove, findById, findAll) for a domain aggregate.
Step 2
Implement it against real storage
Write a concrete repository that maps domain objects to and from the database or ORM.
Step 3
Inject the interface into domain logic
Business/service code depends only on the repository interface, not the concrete implementation.
Step 4
Swap implementations as needed
Provide an in-memory fake for tests or switch data stores without touching domain code.
What Interviewer Expects
- A clear collection-like interface definition (add/remove/find)
- Explanation of decoupling domain logic from persistence technology
- Mention of testability via fake/in-memory repositories
- Awareness that repositories are usually scoped per aggregate root
Common Mistakes
- Turning the repository into a generic CRUD wrapper with no domain meaning
- Leaking ORM-specific types (e.g. query builders) through the repository interface
- Putting business logic inside the repository instead of the domain/service layer
- Confusing Repository with a simple DAO that just wraps table access
Best Answer (HR Friendly)
“The Repository pattern gives business logic a simple, collection-like way to work with data — like add, remove, and find — without knowing whether that data actually lives in a SQL database, a NoSQL store, or an external API. It keeps the core logic clean and easy to test, because you can swap in a fake in-memory repository for tests and swap in a real one for production.”
Code Example
public interface UserRepository {
Optional<User> findById(String id);
List<User> findAll();
void save(User user);
void remove(String id);
}
public class JdbcUserRepository implements UserRepository {
private final DataSource dataSource;
JdbcUserRepository(DataSource dataSource) {
this.dataSource = dataSource;
}
@Override
public Optional<User> findById(String id) {
// SQL query + mapping to User is hidden here
return Optional.empty();
}
@Override
public List<User> findAll() { return List.of(); }
@Override
public void save(User user) { /* INSERT or UPDATE */ }
@Override
public void remove(String id) { /* DELETE */ }
}
class UserService {
private final UserRepository users; // depends on the interface only
UserService(UserRepository users) { this.users = users; }
}Follow-up Questions
- How does the Repository pattern differ from the DAO pattern?
- Should a repository return domain objects or persistence entities?
- How do you unit test code that depends on a repository?
- Is one repository per table correct, or per aggregate root?
MCQ Practice
1. The Repository pattern primarily exposes what kind of interface to callers?
Repositories present a collection-like contract, hiding the actual persistence mechanism.
2. What is the main benefit of programming against a repository interface?
Domain logic depends on the interface, so the underlying data store can change or be faked in tests.
3. In domain-driven design, a repository is typically scoped to?
Repositories are conventionally defined per aggregate root, not per raw table.
Flash Cards
Repository pattern in one line? — A collection-like interface (add/remove/find) that hides persistence details from domain logic.
Main benefit? — Decouples business logic from the database or ORM, enabling easy swapping and testing.
Typical scope? — One repository per aggregate root, not per table.
How does it help tests? — An in-memory fake repository can substitute for the real one without touching domain code.