DAO and Repository are related, but they speak at different levels of the design.

Teams often use DAO and Repository interchangeably, but they are not quite the same idea. DAO is usually a persistence-oriented access abstraction. Repository is more domain-facing and is often framed around aggregate roots and domain concepts. This page clarifies the difference.

OOAD landing page Learning roadmap Previous: GoF in Spring Framework Next: DTO vs Entity vs Value Object

Why This Topic Matters

Why it matters in real Java systems

The distinction matters most when teams are mixing enterprise layering with DDD. If a class is really a data-access wrapper, calling it a repository can make the domain sound richer than it is. If a class is meant to represent aggregate access, calling it a DAO can undersell the model boundary it is supposed to support.

Core Explanation

The main reference idea

A DAO normally speaks in persistence or query terms. A Repository normally speaks in domain terms and is usually aligned with aggregate boundaries. In simple applications, the distinction may be light. In DDD-style applications, the difference becomes more meaningful because repository abstractions communicate model ownership and invariants more clearly.

Concept Breakdown

Key ideas to keep in mind

Reference

DAO

Closer to storage concerns, SQL queries, ORM operations, and data retrieval mechanics.

Reference

Repository

Closer to domain language and aggregate access semantics.

Reference

Practical overlap

Many real codebases mix them, so naming clarity matters more than dogma.

Comparison table

Aspect	DAO	Repository
Primary lens	Persistence access	Domain model access
Typical vocabulary	Rows, queries, records, persistence operations	Aggregates, domain identities, business retrieval
Best fit	Data access layers and integration-centric persistence work	DDD-style aggregate access and domain-facing persistence boundary
Risk	Too storage-shaped for rich domain language	Repository name used for thin CRUD wrappers with no domain meaning

Java Example

Java example in the Order Management domain

Java example: DAO and repository side by side

package org.javaomnibus.reference;

public interface OrderDao {
    OrderRecord findRecordById(String orderId);
}

public interface OrderRepository {
    Order findById(OrderId orderId);
}

Code Walkthrough

Step by step

The DAO exposes a storage-shaped view.
The repository exposes a domain-shaped view.
That distinction is small in syntax but large in design communication.
This page exists to keep the language honest when both patterns appear in one codebase.

Real-World Usage

Where this helps in practice

Naming and layering reviews
DDD adoption in existing enterprise applications
Clarifying data-access responsibilities for teams

Trade-Offs

Trade-offs and when to be careful

Some projects can keep the distinction light, but richer domain models benefit from clearer separation.
Over-policing terminology can be less useful than making the intent explicit in code and documentation.

Common Mistakes

Frequent mistakes to watch for

Naming everything Repository regardless of abstraction level
Using Repository terminology while exposing pure row-level persistence mechanics
Forgetting aggregate boundaries in domain-facing persistence code
Assuming the distinction matters equally in every project

Related concepts

Repositories and Factories Data Access Object / DAO Pattern DTO vs Entity vs Value Object