Data Access Object Dao Pattern - Learning Module

Loading content...

0/246

DAO vs Repository

The Perennial Confusion

Few topics in software architecture generate more confusion—and more heated debate—than the comparison between Data Access Object (DAO) and Repository patterns. Walk into any architecture discussion forum, and you'll find contradictory answers: some claim they're identical, others insist they're fundamentally different, and many conflate them in ways that obscure rather than illuminate.

This confusion isn't surprising. Both patterns abstract data persistence. Both hide database details. Both provide interfaces for CRUD operations. From a distance, they look nearly identical. But understanding their distinct origins, conceptual foundations, and appropriate applications is essential for architectural clarity.

What You Will Learn

This page provides a comprehensive comparison of DAO and Repository patterns. You'll learn their distinct origins, conceptual differences, practical overlaps, and—most importantly—clear guidance for when to use each pattern. By the end, the confusion will be replaced with principled understanding.

Distinct Historical Origins

To understand the distinction, we must trace each pattern to its origins. They emerged from different communities, solving problems through different lenses.

DAO: Born from Enterprise Java

The DAO pattern emerged from Sun Microsystems' Core J2EE Patterns catalog (circa 2001-2003). Its primary concern was technical: separating the mechanics of data access (JDBC connections, SQL execution, result set handling) from business logic. The pattern was deeply influenced by the Java EE ecosystem's layered architecture.

DAO's vocabulary reflects its technical focus: it speaks of data sources, connections, queries, and data transfer objects. The pattern is database-centric—it exists to abstract the database.

Repository: Born from Domain-Driven Design

The Repository pattern emerged from Eric Evans' Domain-Driven Design (2003), approaching persistence from an entirely different angle. Evans' concern was not technical but conceptual: how should domain experts and developers think about object persistence?

Evans positioned the Repository as a domain concept, not an infrastructure detail. A Repository presents the illusion of an in-memory collection of domain objects. The domain model interacts with the Repository as if all objects were already in memory, unaware of the underlying persistence mechanism.

Repository's vocabulary reflects its domain focus: it speaks of aggregate roots, specifications, reconstitution, and domain integrity. The pattern is domain-centric—it exists to serve the domain model.

Pattern Origins Comparison
Aspect	DAO Pattern	Repository Pattern
Origin	Core J2EE Patterns (Sun Microsystems)	Domain-Driven Design (Eric Evans)
Year	~2001-2003	2003
Community	Enterprise Java	Domain modeling / Object-oriented design
Primary Concern	Database abstraction	Domain model integrity
Mental Model	Data access layer component	In-memory collection of aggregates
Driving Force	Technical separation of concerns	Ubiquitous language and domain purity

Context Matters

Understanding these origins isn't academic pedantry—it explains why the patterns look similar but carry different implications. DAO was designed to solve a technical problem; Repository was designed to preserve domain model integrity. This difference affects everything from interface design to where the patterns live in your architecture.

Conceptual Foundations

Let's examine the conceptual foundations that make these patterns distinct, even when their implementations look similar.

DAO: Technical Abstraction Layer

The DAO's conceptual model is straightforward: it's a translation layer between the object-oriented application and the relational (or otherwise structured) database. Think of DAO as an adapter—it adapts database operations to an interface the application can consume.

Implications of this model:

DAO methods often map closely to database operations (CRUD)
DAO interfaces may include database-influenced concepts (pagination, ordering)
A single table often corresponds to a single DAO
DAO can exist without a rich domain model

Repository: Collection Abstraction

The Repository's conceptual model is more sophisticated: it presents the illusion that all domain objects exist in memory. When you ask a Repository for an object, it's as if you're asking an in-memory collection—the Repository hides the fact that objects must be reconstituted from persistent storage.

Implications of this model:

Repository methods use domain language (findSubscribersExpiringWithin)
Repository operates on aggregate roots, respecting domain boundaries
Repository enforces domain invariants during reconstitution
Repository doesn't make sense without a domain model to serve

conceptual-difference.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
// ─────────────────────────────────────────────────────────
// DAO: Focused on the TABLE/DATABASE structure
// ─────────────────────────────────────────────────────────
 
interface UserDAO {
    // Methods reflect database operations
    insert(user: UserDTO): Promise<void>;      // INSERT
    update(user: UserDTO): Promise<void>;      // UPDATE
    delete(id: string): Promise<void>;         // DELETE
    selectById(id: string): Promise<UserDTO>;  // SELECT
    selectByEmail(email: string): Promise<UserDTO>;
    
    // Might include database-specific concerns
    selectWithPagination(offset: number, limit: number): Promise<UserDTO[]>;
    count(): Promise<number>;
    
    // May have multiple DAOs for related tables
    // UserDAO, UserPreferencesDAO, UserAddressDAO...
}
 
// ─────────────────────────────────────────────────────────
// REPOSITORY: Focused on the DOMAIN AGGREGATE
// ─────────────────────────────────────────────────────────
 
interface UserRepository {
    // Methods reflect domain operations (collection-like)
    add(user: User): Promise<void>;            // Like adding to a collection
    remove(user: User): Promise<void>;         // Like removing from a collection
    
    // Domain-focused queries
    findById(userId: UserId): Promise<User | null>;
    findByEmail(email: Email): Promise<User | null>;
    
    // Uses domain language and value objects
    findActiveSubscribersInRegion(region: Region): Promise<User[]>;
    findRequiringPasswordReset(): Promise<User[]>;
    
    // Works with the COMPLETE AGGREGATE
    // User includes preferences, addresses, etc.
    // No separate "UserPreferencesRepository" needed
}
 
// ─────────────────────────────────────────────────────────
// KEY DIFFERENCE: What the pattern operates on
// ─────────────────────────────────────────────────────────
 
// DAO operates on DATA (often DTOs, close to database rows)
type UserDTO = {
    id: string;
    email: string;
    name: string;
    status: string;
    tier: string;
    created_at: Date;
    updated_at: Date;
};
 
// Repository operates on DOMAIN AGGREGATES (rich domain objects)
class User {
    private constructor(
        private readonly _id: UserId,
        private readonly _email: Email,
        private _profile: UserProfile,
        private _subscription: Subscription,
        private _addresses: Address[]
    ) {}
    
    // Rich behavior, domain logic encapsulated
    upgradeSubscription(tier: SubscriptionTier): void {
        this._subscription = this._subscription.upgradeTo(tier);
        this.addDomainEvent(new UserSubscriptionUpgraded(this._id, tier));
    }
    
    addShippingAddress(address: Address): void {
        if (this._addresses.length >= 5) {
            throw new AddressLimitExceeded();
        }
        this._addresses.push(address);
    }
}

The Collection Metaphor

Eric Evans describes Repository as providing 'the illusion of an in-memory collection.' When working with a Repository, pretend all your domain objects are already loaded in a Set or List. You add to it, remove from it, and query it—the Repository handles the persistence reality transparently.

Interface Design Differences

The conceptual differences manifest in interface design. Examining side-by-side comparisons illuminates the patterns' different orientations.

DAO Interface Characteristics

•Methods map to CRUD operations
•Often returns DTOs or maps
•Table-oriented granularity
•May expose pagination details
•Query methods accept primitives
•Insert/Update distinction
•Multiple DAOs for related tables

Repository Interface Characteristics

•Methods use domain language
•Returns rich domain aggregates
•Aggregate-oriented granularity
•Hides pagination behind specs
•Query methods use value objects
•Add/Save abstracts create/update
•One Repository per Aggregate Root

interface-comparison.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
// ─────────────────────────────────────────────────────────
// DAO INTERFACE EXAMPLE
// ─────────────────────────────────────────────────────────
 
interface OrderDAO {
    // CRUD-oriented method names
    insert(order: OrderDTO): Promise<string>;
    update(order: OrderDTO): Promise<void>;
    delete(orderId: string): Promise<void>;
    
    // Separate table queries
    selectById(orderId: string): Promise<OrderDTO | null>;
    selectByCustomerId(customerId: string): Promise<OrderDTO[]>;
    
    // Exposes database pagination directly
    selectWithPagination(
        filter: OrderFilter,
        offset: number,
        limit: number,
        sortBy: string,
        sortOrder: 'ASC' | 'DESC'
    ): Promise<{orders: OrderDTO[], total: number}>;
    
    // Might need related DAOs
    // OrderLineItemDAO, OrderPaymentDAO, etc.
}
 
interface OrderLineItemDAO {
    insertBatch(orderId: string, items: OrderLineItemDTO[]): Promise<void>;
    selectByOrderId(orderId: string): Promise<OrderLineItemDTO[]>;
    // ...
}
 
// ─────────────────────────────────────────────────────────
// REPOSITORY INTERFACE EXAMPLE
// ─────────────────────────────────────────────────────────
 
interface OrderRepository {
    // Collection-like methods: add, save, remove
    add(order: Order): Promise<void>;            // New aggregate
    save(order: Order): Promise<void>;           // Persist changes
    remove(order: Order): Promise<void>;         // Delete aggregate
    
    // Domain-typed lookups
    findById(orderId: OrderId): Promise<Order | null>;
    
    // Queries using value objects and domain types
    findByCustomer(customerId: CustomerId): Promise<Order[]>;
    
    // Domain-meaningful query methods
    findPendingOrdersRequiringFulfillment(): Promise<Order[]>;
    findOrdersExceedingAmount(threshold: Money): Promise<Order[]>;
    
    // Specification pattern for complex queries
    findMatching(specification: OrderSpecification): Promise<Order[]>;
    
    // The Order aggregate includes its line items, payments, etc.
    // No separate OrderLineItemRepository needed
}
 
// ─────────────────────────────────────────────────────────
// REPOSITORY USING SPECIFICATION PATTERN
// ─────────────────────────────────────────────────────────
 
// Specifications encapsulate query criteria in domain terms
interface OrderSpecification {
    isSatisfiedBy(order: Order): boolean;
    toSql(): { where: string; params: any[] };  // For DB translation
}
 
class PendingHighValueOrder implements OrderSpecification {
    constructor(private readonly threshold: Money) {}
    
    isSatisfiedBy(order: Order): boolean {
        return order.status === OrderStatus.PENDING 
            && order.totalAmount.greaterThan(this.threshold);
    }
    
    toSql(): { where: string; params: any[] } {
        return {
            where: 'status = $1 AND total_amount > $2',
            params: ['PENDING', this.threshold.toCents()]
        };
    }
}
 
// Usage in service
const highValuePending = await orderRepository.findMatching(
    new PendingHighValueOrder(Money.dollars(1000))
);

Aggregate Integrity

A critical Repository responsibility is maintaining aggregate integrity. When you retrieve an Order, the Repository must reconstitute the complete aggregate—order lines, payment info, shipping details—ensuring all invariants hold. DAOs typically fetch table-by-table, leaving aggregate reconstitution to calling code.

Architectural Placement

Where these patterns live in your architecture reveals their different orientations.

DAO Placement:

DAO exists firmly in the infrastructure/data access layer. It's an implementation detail—a technical component that handles database mechanics. The business layer depends on DAO interfaces, but DAO has no awareness of business rules.

Repository Placement:

Repository straddles a boundary. The Repository interface is part of the domain layer (or domain-adjacent application layer). It's a domain concept—part of the ubiquitous language. The Repository implementation lives in the infrastructure layer, but the interface belongs to the domain.

This distinction has profound implications for dependency direction:

architectural-placement.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
// ═══════════════════════════════════════════════════════════
// DAO ARRANGEMENT: Interface and implementation in infrastructure
// ═══════════════════════════════════════════════════════════
 
// infrastructure/dao/user-dao.interface.ts
export interface IUserDAO {
    insert(user: UserDTO): Promise<string>;
    selectById(id: string): Promise<UserDTO | null>;
    update(user: UserDTO): Promise<void>;
    delete(id: string): Promise<void>;
}
 
// infrastructure/dao/postgres-user-dao.ts
export class PostgresUserDAO implements IUserDAO {
    // ... implementation
}
 
// services/user-service.ts
// Service depends on DAO from infrastructure
import { IUserDAO } from '../infrastructure/dao/user-dao.interface';
 
export class UserService {
    constructor(private readonly userDAO: IUserDAO) {}
    
    async createUser(dto: CreateUserDTO): Promise<UserDTO> {
        // Service contains business logic, uses DAO for persistence
        const userData = { ...dto, createdAt: new Date() };
        const id = await this.userDAO.insert(userData);
        return this.userDAO.selectById(id);
    }
}
 
 
// ═══════════════════════════════════════════════════════════
// REPOSITORY ARRANGEMENT: Interface in domain, implementation in infrastructure
// ═══════════════════════════════════════════════════════════
 
// domain/repositories/user-repository.interface.ts
// This lives in the DOMAIN layer - part of the ubiquitous language
export interface UserRepository {
    findById(userId: UserId): Promise<User | null>;
    findByEmail(email: Email): Promise<User | null>;
    save(user: User): Promise<void>;
    remove(user: User): Promise<void>;
}
 
// domain/entities/user.ts
// Rich domain entity with behavior
export class User {
    // Domain logic lives here
}
 
// infrastructure/persistence/postgres-user-repository.ts
// Implementation in infrastructure, implements domain interface
import { UserRepository } from '../../domain/repositories/user-repository.interface';
import { User, UserId, Email } from '../../domain/entities/user';
 
export class PostgresUserRepository implements UserRepository {
    async findById(userId: UserId): Promise<User | null> {
        // Implementation reconstitutes full aggregate
        const userData = await this.pool.query(/*...*/);
        if (!userData.rows[0]) return null;
        
        const preferences = await this.loadPreferences(userId);
        const addresses = await this.loadAddresses(userId);
        
        return User.reconstitute(userData.rows[0], preferences, addresses);
    }
    
    async save(user: User): Promise<void> {
        // Implementation persists complete aggregate
        await this.persistUserData(user);
        await this.persistPreferences(user.preferences);
        await this.persistAddresses(user.addresses);
    }
}
 
// application/use-cases/register-user.ts
// Use case depends on Repository interface from domain (not infrastructure)
import { UserRepository } from '../../domain/repositories/user-repository.interface';
 
export class RegisterUserUseCase {
    constructor(private readonly userRepository: UserRepository) {}
    
    async execute(command: RegisterUserCommand): Promise<User> {
        const existingUser = await this.userRepository.findByEmail(
            new Email(command.email)
        );
        if (existingUser) {
            throw new EmailAlreadyRegistered(command.email);
        }
        
        const user = User.create(command.name, new Email(command.email));
        await this.userRepository.save(user);
        return user;
    }
}

Layer Placement Summary
Component	DAO Pattern	Repository Pattern
Interface Location	Data Access / Infrastructure Layer	Domain Layer
Implementation Location	Data Access / Infrastructure Layer	Infrastructure Layer
Dependency Direction	Business → Infrastructure	Infrastructure → Domain (inverted)
Domain Coupling	Low (DAO is database-focused)	High (Repository serves domain model)

Dependency Inversion

Repository naturally implements Dependency Inversion Principle (DIP). The domain defines what it needs (Repository interface), and infrastructure provides it (concrete implementation). This keeps the domain independent of infrastructure choices—a core Clean Architecture principle.

Practical Overlaps and Common Confusion

Despite their different origins and conceptual foundations, the patterns overlap significantly in practice. This explains why developers often use them interchangeably—and why that's not always wrong.

Where They Overlap:

Shared Characteristics

•Both abstract persistence — Clients interact through interfaces, not database connections
•Both hide implementation details — SQL, connection pooling, retry logic are encapsulated
•Both enable testing — Mock implementations replace database for unit tests
•Both provide CRUD-like operations — Create, Read, Update, Delete (or Add, Find, Save, Remove)
•Both can return domain objects — Even DAOs can return rich domain entities if designed that way

Why The Confusion Persists:

Inconsistent terminology in frameworks — Many ORMs use 'Repository' to mean what is conceptually closer to DAO. Spring Data's CrudRepository is essentially a generic DAO.
DDD is poorly understood — Without understanding Domain-Driven Design, Repository's collection semantics and aggregate focus seem like arbitrary distinctions.
Simple applications don't need the distinction — In CRUD applications without rich domain models, the patterns genuinely converge.
Mixed usage in tutorials — Online resources frequently conflate the patterns or use repository/DAO based on the author's background.

The Honest Truth:

In practice, many so-called 'Repositories' are functionally DAOs, and that's perfectly acceptable for many applications. The distinction becomes critical only when:

You have a rich domain model with complex behavior
You're practicing Domain-Driven Design
Aggregate integrity enforcement matters
You want the domain layer independent of persistence decisions

Pragmatic Naming

If your team uses 'Repository' for what is technically a DAO—and everyone understands what it does—don't fight it. Consistency within your codebase matters more than theoretical purity. Just ensure the abstraction serves its purpose: isolating persistence details.

When to Use Each Pattern

With the conceptual and practical differences clear, when should you choose each pattern?

Choose DAO When:

DAO-Appropriate Contexts

•Simple CRUD applications — When business logic is thin and operations map directly to database tables
•Data-centric systems — Reporting systems, ETL pipelines, admin dashboards where data is the product
•No rich domain model — When entities are essentially record types without complex behavior
•Multiple data sources — When you need to abstract heterogeneous storage (SQL + NoSQL + Files)
•Legacy system integration — When retrofitting abstraction onto existing table-oriented code
•Table-per-DAO mapping — When your design naturally maps one DAO to one database table

Choose Repository When:

Repository-Appropriate Contexts

•Practicing Domain-Driven Design — Repository is integral to DDD's tactical patterns
•Rich domain model — When entities have complex behavior, invariants, and relationships
•Aggregate-oriented design — When you've identified aggregates with aggregate roots
•Domain layer independence — When you want the domain completely ignorant of persistence
•Complex reconstitution — When loading an entity requires assembling multiple related objects
•Specification pattern usage — When you want domain-expressed query conditions

decision-examples.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
// ═══════════════════════════════════════════════════════════
// SCENARIO 1: Simple Admin Dashboard - DAO is appropriate
// ═══════════════════════════════════════════════════════════
 
// Simple CRUD operations, thin business logic
// DAO maps cleanly to the domain needs
 
interface ProductDAO {
    findAll(page: number, size: number): Promise<ProductDTO[]>;
    findById(id: string): Promise<ProductDTO | null>;
    insert(product: ProductDTO): Promise<string>;
    update(product: ProductDTO): Promise<void>;
    delete(id: string): Promise<void>;
}
 
class ProductController {
    constructor(private readonly productDAO: ProductDAO) {}
    
    async listProducts(page: number, size: number) {
        return this.productDAO.findAll(page, size);
    }
    
    async updateProduct(id: string, updates: Partial<ProductDTO>) {
        const existing = await this.productDAO.findById(id);
        if (!existing) throw new NotFoundError();
        await this.productDAO.update({ ...existing, ...updates });
    }
}
 
 
// ═══════════════════════════════════════════════════════════
// SCENARIO 2: E-Commerce Order System - Repository is appropriate
// ═══════════════════════════════════════════════════════════
 
// Rich domain model with complex aggregates
// Order is an aggregate root containing line items, payments, shipping
 
interface OrderRepository {
    findById(orderId: OrderId): Promise<Order | null>;
    findByCustomer(customerId: CustomerId): Promise<Order[]>;
    save(order: Order): Promise<void>;
}
 
// Rich domain aggregate
class Order {
    private items: OrderLineItem[] = [];
    private payments: Payment[] = [];
    private shipment: Shipment | null = null;
    
    addItem(product: Product, quantity: number): void {
        if (this.status !== OrderStatus.DRAFT) {
            throw new CannotModifySubmittedOrder();
        }
        const item = OrderLineItem.create(product, quantity);
        this.items.push(item);
        this.recalculateTotals();
    }
    
    applyPayment(payment: Payment): void {
        if (this.payments.some(p => p.id.equals(payment.id))) {
            throw new DuplicatePayment();
        }
        this.payments.push(payment);
        if (this.isPaidInFull()) {
            this.transitionTo(OrderStatus.READY_FOR_FULFILLMENT);
        }
    }
    
    // Complex reconstitution requires Repository pattern
    static reconstitute(
        state: OrderState,
        items: OrderLineItem[],
        payments: Payment[],
        shipment: Shipment | null
    ): Order {
        const order = new Order();
        Object.assign(order, state);
        order.items = items;
        order.payments = payments;
        order.shipment = shipment;
        return order;
    }
}
 
// Use case relies on Repository for aggregate integrity
class SubmitOrderUseCase {
    constructor(
        private readonly orderRepository: OrderRepository,
        private readonly inventoryService: InventoryService
    ) {}
    
    async execute(command: SubmitOrderCommand): Promise<void> {
        const order = await this.orderRepository.findById(
            new OrderId(command.orderId)
        );
        
        if (!order) throw new OrderNotFound();
        
        // Check inventory for complete aggregate
        for (const item of order.items) {
            await this.inventoryService.reserve(item.productId, item.quantity);
        }
        
        order.submit();  // Domain behavior
        
        await this.orderRepository.save(order);  // Persists complete aggregate
    }
}

Hybrid Approaches

In sophisticated systems, you might use both patterns together, each serving its appropriate context.

Repository Implemented Using DAOs:

A common architecture uses Repository for aggregate management while DAO handles the actual database interactions. The Repository becomes a coordinator that uses multiple DAOs to reconstitute aggregates.

hybrid-approach.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
// ─────────────────────────────────────────────────────────
// HYBRID: Repository uses DAOs internally
// ─────────────────────────────────────────────────────────
 
// DAOs handle table-level access
interface OrderDAO {
    selectById(id: string): Promise<OrderRow | null>;
    insert(row: OrderRow): Promise<void>;
    update(row: OrderRow): Promise<void>;
}
 
interface OrderLineItemDAO {
    selectByOrderId(orderId: string): Promise<OrderLineItemRow[]>;
    insertBatch(items: OrderLineItemRow[]): Promise<void>;
    deleteByOrderId(orderId: string): Promise<void>;
}
 
interface PaymentDAO {
    selectByOrderId(orderId: string): Promise<PaymentRow[]>;
    insert(row: PaymentRow): Promise<void>;
}
 
// Repository coordinates DAOs to manage the aggregate
class PostgresOrderRepository implements OrderRepository {
    constructor(
        private readonly orderDAO: OrderDAO,
        private readonly lineItemDAO: OrderLineItemDAO,
        private readonly paymentDAO: PaymentDAO,
        private readonly aggregateMapper: OrderAggregateMapper
    ) {}
    
    async findById(orderId: OrderId): Promise<Order | null> {
        // Coordinate multiple DAOs to load complete aggregate
        const orderRow = await this.orderDAO.selectById(orderId.value);
        if (!orderRow) return null;
        
        const lineItemRows = await this.lineItemDAO.selectByOrderId(orderId.value);
        const paymentRows = await this.paymentDAO.selectByOrderId(orderId.value);
        
        // Use mapper to reconstitute the aggregate
        return this.aggregateMapper.toDomain(orderRow, lineItemRows, paymentRows);
    }
    
    async save(order: Order): Promise<void> {
        // Coordinate DAOs to persist complete aggregate
        const { orderRow, lineItemRows, paymentRows } = 
            this.aggregateMapper.toRows(order);
        
        // Transaction-aware persistence
        await this.runInTransaction(async () => {
            await this.orderDAO.update(orderRow);
            
            // Replace line items (simplest approach)
            await this.lineItemDAO.deleteByOrderId(order.id.value);
            await this.lineItemDAO.insertBatch(lineItemRows);
            
            // Only insert new payments
            for (const payment of order.newPayments) {
                await this.paymentDAO.insert(
                    this.aggregateMapper.paymentToRow(payment)
                );
            }
        });
    }
}
 
// ─────────────────────────────────────────────────────────
// Benefits of this approach:
// - DAOs remain simple, table-focused, reusable
// - Repository handles aggregate complexity
// - Mapping logic is centralized
// - Each layer has clear responsibility
// ─────────────────────────────────────────────────────────

Layered Abstractions

This layered approach—Repository over DAOs—combines the best of both patterns. DAOs provide reusable, testable table access. Repositories provide domain-oriented aggregate management. Neither pattern's strengths are sacrificed.

Summary: DAO vs Repository

Let's consolidate the essential distinctions between DAO and Repository patterns:

DAO vs Repository Summary
Dimension	DAO Pattern	Repository Pattern
Origin	Core J2EE Patterns	Domain-Driven Design
Mental Model	Database abstraction layer	In-memory collection of aggregates
Focus	Technical (table/data access)	Domain (aggregate management)
Granularity	Table-oriented	Aggregate-oriented
Interface Location	Infrastructure layer	Domain layer
Returns	DTOs or simple entities	Rich domain aggregates
Query Language	Technical (offset, limit)	Domain (specifications)
Best For	CRUD apps, data-centric systems	DDD, complex domain models

Key Takeaways

•Different origins, different goals — DAO abstracts database mechanics; Repository abstracts aggregate persistence.
•Interface placement matters — Repository interfaces belong in the domain; DAO interfaces in infrastructure.
•Aggregates vs tables — Repository works with complete aggregates; DAO works with table rows.
•Practical overlap exists — In simple apps, the patterns converge; distinction matters for rich domains.
•Hybrid approaches work — Repository can coordinate DAOs for complex aggregate persistence.
•Choose based on context — CRUD apps favor DAO; DDD systems require Repository.

What's Next:

With the theoretical distinction clear, the next page dives into practical DAO Implementation. You'll learn concrete techniques for building robust DAO implementations, including connection management, query building, result mapping, and error handling.

Page Complete

You now understand the fundamental differences between DAO and Repository patterns—their origins, conceptual models, interface designs, and appropriate use cases. This clarity will inform your architectural decisions in future projects.

DAO vs Repository

The Perennial Confusion

What You Will Learn

Distinct Historical Origins

To understand the distinction, we must trace each pattern to its origins. They emerged from different communities, solving problems through different lenses.

DAO: Born from Enterprise Java

Repository: Born from Domain-Driven Design

Pattern Origins Comparison
Aspect	DAO Pattern	Repository Pattern
Origin	Core J2EE Patterns (Sun Microsystems)	Domain-Driven Design (Eric Evans)
Year	~2001-2003	2003
Community	Enterprise Java	Domain modeling / Object-oriented design
Primary Concern	Database abstraction	Domain model integrity
Mental Model	Data access layer component	In-memory collection of aggregates
Driving Force	Technical separation of concerns	Ubiquitous language and domain purity

Context Matters

Conceptual Foundations

Let's examine the conceptual foundations that make these patterns distinct, even when their implementations look similar.

DAO: Technical Abstraction Layer

Implications of this model:

DAO methods often map closely to database operations (CRUD)
DAO interfaces may include database-influenced concepts (pagination, ordering)
A single table often corresponds to a single DAO
DAO can exist without a rich domain model

Repository: Collection Abstraction

Implications of this model:

Repository methods use domain language (findSubscribersExpiringWithin)
Repository operates on aggregate roots, respecting domain boundaries
Repository enforces domain invariants during reconstitution
Repository doesn't make sense without a domain model to serve

conceptual-difference.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
// ─────────────────────────────────────────────────────────
// DAO: Focused on the TABLE/DATABASE structure
// ─────────────────────────────────────────────────────────
 
interface UserDAO {
    // Methods reflect database operations
    insert(user: UserDTO): Promise<void>;      // INSERT
    update(user: UserDTO): Promise<void>;      // UPDATE
    delete(id: string): Promise<void>;         // DELETE
    selectById(id: string): Promise<UserDTO>;  // SELECT
    selectByEmail(email: string): Promise<UserDTO>;
    
    // Might include database-specific concerns
    selectWithPagination(offset: number, limit: number): Promise<UserDTO[]>;
    count(): Promise<number>;
    
    // May have multiple DAOs for related tables
    // UserDAO, UserPreferencesDAO, UserAddressDAO...
}
 
// ─────────────────────────────────────────────────────────
// REPOSITORY: Focused on the DOMAIN AGGREGATE
// ─────────────────────────────────────────────────────────
 
interface UserRepository {
    // Methods reflect domain operations (collection-like)
    add(user: User): Promise<void>;            // Like adding to a collection
    remove(user: User): Promise<void>;         // Like removing from a collection
    
    // Domain-focused queries
    findById(userId: UserId): Promise<User | null>;
    findByEmail(email: Email): Promise<User | null>;
    
    // Uses domain language and value objects
    findActiveSubscribersInRegion(region: Region): Promise<User[]>;
    findRequiringPasswordReset(): Promise<User[]>;
    
    // Works with the COMPLETE AGGREGATE
    // User includes preferences, addresses, etc.
    // No separate "UserPreferencesRepository" needed
}
 
// ─────────────────────────────────────────────────────────
// KEY DIFFERENCE: What the pattern operates on
// ─────────────────────────────────────────────────────────
 
// DAO operates on DATA (often DTOs, close to database rows)
type UserDTO = {
    id: string;
    email: string;
    name: string;
    status: string;
    tier: string;
    created_at: Date;
    updated_at: Date;
};
 
// Repository operates on DOMAIN AGGREGATES (rich domain objects)
class User {
    private constructor(
        private readonly _id: UserId,
        private readonly _email: Email,
        private _profile: UserProfile,
        private _subscription: Subscription,
        private _addresses: Address[]
    ) {}
    
    // Rich behavior, domain logic encapsulated
    upgradeSubscription(tier: SubscriptionTier): void {
        this._subscription = this._subscription.upgradeTo(tier);
        this.addDomainEvent(new UserSubscriptionUpgraded(this._id, tier));
    }
    
    addShippingAddress(address: Address): void {
        if (this._addresses.length >= 5) {
            throw new AddressLimitExceeded();
        }
        this._addresses.push(address);
    }
}

The Collection Metaphor

Interface Design Differences

The conceptual differences manifest in interface design. Examining side-by-side comparisons illuminates the patterns' different orientations.

DAO Interface Characteristics

•Methods map to CRUD operations
•Often returns DTOs or maps
•Table-oriented granularity
•May expose pagination details
•Query methods accept primitives
•Insert/Update distinction
•Multiple DAOs for related tables

Repository Interface Characteristics

•Methods use domain language
•Returns rich domain aggregates
•Aggregate-oriented granularity
•Hides pagination behind specs
•Query methods use value objects
•Add/Save abstracts create/update
•One Repository per Aggregate Root

interface-comparison.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
// ─────────────────────────────────────────────────────────
// DAO INTERFACE EXAMPLE
// ─────────────────────────────────────────────────────────
 
interface OrderDAO {
    // CRUD-oriented method names
    insert(order: OrderDTO): Promise<string>;
    update(order: OrderDTO): Promise<void>;
    delete(orderId: string): Promise<void>;
    
    // Separate table queries
    selectById(orderId: string): Promise<OrderDTO | null>;
    selectByCustomerId(customerId: string): Promise<OrderDTO[]>;
    
    // Exposes database pagination directly
    selectWithPagination(
        filter: OrderFilter,
        offset: number,
        limit: number,
        sortBy: string,
        sortOrder: 'ASC' | 'DESC'
    ): Promise<{orders: OrderDTO[], total: number}>;
    
    // Might need related DAOs
    // OrderLineItemDAO, OrderPaymentDAO, etc.
}
 
interface OrderLineItemDAO {
    insertBatch(orderId: string, items: OrderLineItemDTO[]): Promise<void>;
    selectByOrderId(orderId: string): Promise<OrderLineItemDTO[]>;
    // ...
}
 
// ─────────────────────────────────────────────────────────
// REPOSITORY INTERFACE EXAMPLE
// ─────────────────────────────────────────────────────────
 
interface OrderRepository {
    // Collection-like methods: add, save, remove
    add(order: Order): Promise<void>;            // New aggregate
    save(order: Order): Promise<void>;           // Persist changes
    remove(order: Order): Promise<void>;         // Delete aggregate
    
    // Domain-typed lookups
    findById(orderId: OrderId): Promise<Order | null>;
    
    // Queries using value objects and domain types
    findByCustomer(customerId: CustomerId): Promise<Order[]>;
    
    // Domain-meaningful query methods
    findPendingOrdersRequiringFulfillment(): Promise<Order[]>;
    findOrdersExceedingAmount(threshold: Money): Promise<Order[]>;
    
    // Specification pattern for complex queries
    findMatching(specification: OrderSpecification): Promise<Order[]>;
    
    // The Order aggregate includes its line items, payments, etc.
    // No separate OrderLineItemRepository needed
}
 
// ─────────────────────────────────────────────────────────
// REPOSITORY USING SPECIFICATION PATTERN
// ─────────────────────────────────────────────────────────
 
// Specifications encapsulate query criteria in domain terms
interface OrderSpecification {
    isSatisfiedBy(order: Order): boolean;
    toSql(): { where: string; params: any[] };  // For DB translation
}
 
class PendingHighValueOrder implements OrderSpecification {
    constructor(private readonly threshold: Money) {}
    
    isSatisfiedBy(order: Order): boolean {
        return order.status === OrderStatus.PENDING 
            && order.totalAmount.greaterThan(this.threshold);
    }
    
    toSql(): { where: string; params: any[] } {
        return {
            where: 'status = $1 AND total_amount > $2',
            params: ['PENDING', this.threshold.toCents()]
        };
    }
}
 
// Usage in service
const highValuePending = await orderRepository.findMatching(
    new PendingHighValueOrder(Money.dollars(1000))
);

Aggregate Integrity

Architectural Placement

Where these patterns live in your architecture reveals their different orientations.

DAO Placement:

Repository Placement:

This distinction has profound implications for dependency direction:

architectural-placement.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
// ═══════════════════════════════════════════════════════════
// DAO ARRANGEMENT: Interface and implementation in infrastructure
// ═══════════════════════════════════════════════════════════
 
// infrastructure/dao/user-dao.interface.ts
export interface IUserDAO {
    insert(user: UserDTO): Promise<string>;
    selectById(id: string): Promise<UserDTO | null>;
    update(user: UserDTO): Promise<void>;
    delete(id: string): Promise<void>;
}
 
// infrastructure/dao/postgres-user-dao.ts
export class PostgresUserDAO implements IUserDAO {
    // ... implementation
}
 
// services/user-service.ts
// Service depends on DAO from infrastructure
import { IUserDAO } from '../infrastructure/dao/user-dao.interface';
 
export class UserService {
    constructor(private readonly userDAO: IUserDAO) {}
    
    async createUser(dto: CreateUserDTO): Promise<UserDTO> {
        // Service contains business logic, uses DAO for persistence
        const userData = { ...dto, createdAt: new Date() };
        const id = await this.userDAO.insert(userData);
        return this.userDAO.selectById(id);
    }
}
 
 
// ═══════════════════════════════════════════════════════════
// REPOSITORY ARRANGEMENT: Interface in domain, implementation in infrastructure
// ═══════════════════════════════════════════════════════════
 
// domain/repositories/user-repository.interface.ts
// This lives in the DOMAIN layer - part of the ubiquitous language
export interface UserRepository {
    findById(userId: UserId): Promise<User | null>;
    findByEmail(email: Email): Promise<User | null>;
    save(user: User): Promise<void>;
    remove(user: User): Promise<void>;
}
 
// domain/entities/user.ts
// Rich domain entity with behavior
export class User {
    // Domain logic lives here
}
 
// infrastructure/persistence/postgres-user-repository.ts
// Implementation in infrastructure, implements domain interface
import { UserRepository } from '../../domain/repositories/user-repository.interface';
import { User, UserId, Email } from '../../domain/entities/user';
 
export class PostgresUserRepository implements UserRepository {
    async findById(userId: UserId): Promise<User | null> {
        // Implementation reconstitutes full aggregate
        const userData = await this.pool.query(/*...*/);
        if (!userData.rows[0]) return null;
        
        const preferences = await this.loadPreferences(userId);
        const addresses = await this.loadAddresses(userId);
        
        return User.reconstitute(userData.rows[0], preferences, addresses);
    }
    
    async save(user: User): Promise<void> {
        // Implementation persists complete aggregate
        await this.persistUserData(user);
        await this.persistPreferences(user.preferences);
        await this.persistAddresses(user.addresses);
    }
}
 
// application/use-cases/register-user.ts
// Use case depends on Repository interface from domain (not infrastructure)
import { UserRepository } from '../../domain/repositories/user-repository.interface';
 
export class RegisterUserUseCase {
    constructor(private readonly userRepository: UserRepository) {}
    
    async execute(command: RegisterUserCommand): Promise<User> {
        const existingUser = await this.userRepository.findByEmail(
            new Email(command.email)
        );
        if (existingUser) {
            throw new EmailAlreadyRegistered(command.email);
        }
        
        const user = User.create(command.name, new Email(command.email));
        await this.userRepository.save(user);
        return user;
    }
}

Layer Placement Summary
Component	DAO Pattern	Repository Pattern
Interface Location	Data Access / Infrastructure Layer	Domain Layer
Implementation Location	Data Access / Infrastructure Layer	Infrastructure Layer
Dependency Direction	Business → Infrastructure	Infrastructure → Domain (inverted)
Domain Coupling	Low (DAO is database-focused)	High (Repository serves domain model)

Dependency Inversion

Practical Overlaps and Common Confusion

Where They Overlap:

Shared Characteristics

•Both abstract persistence — Clients interact through interfaces, not database connections
•Both hide implementation details — SQL, connection pooling, retry logic are encapsulated
•Both enable testing — Mock implementations replace database for unit tests
•Both provide CRUD-like operations — Create, Read, Update, Delete (or Add, Find, Save, Remove)
•Both can return domain objects — Even DAOs can return rich domain entities if designed that way

Why The Confusion Persists:

Inconsistent terminology in frameworks — Many ORMs use 'Repository' to mean what is conceptually closer to DAO. Spring Data's CrudRepository is essentially a generic DAO.
DDD is poorly understood — Without understanding Domain-Driven Design, Repository's collection semantics and aggregate focus seem like arbitrary distinctions.
Simple applications don't need the distinction — In CRUD applications without rich domain models, the patterns genuinely converge.
Mixed usage in tutorials — Online resources frequently conflate the patterns or use repository/DAO based on the author's background.

The Honest Truth:

In practice, many so-called 'Repositories' are functionally DAOs, and that's perfectly acceptable for many applications. The distinction becomes critical only when:

You have a rich domain model with complex behavior
You're practicing Domain-Driven Design
Aggregate integrity enforcement matters
You want the domain layer independent of persistence decisions

Pragmatic Naming

When to Use Each Pattern

With the conceptual and practical differences clear, when should you choose each pattern?

Choose DAO When:

DAO-Appropriate Contexts

•Simple CRUD applications — When business logic is thin and operations map directly to database tables
•Data-centric systems — Reporting systems, ETL pipelines, admin dashboards where data is the product
•No rich domain model — When entities are essentially record types without complex behavior
•Multiple data sources — When you need to abstract heterogeneous storage (SQL + NoSQL + Files)
•Legacy system integration — When retrofitting abstraction onto existing table-oriented code
•Table-per-DAO mapping — When your design naturally maps one DAO to one database table

Choose Repository When:

Repository-Appropriate Contexts

•Practicing Domain-Driven Design — Repository is integral to DDD's tactical patterns
•Rich domain model — When entities have complex behavior, invariants, and relationships
•Aggregate-oriented design — When you've identified aggregates with aggregate roots
•Domain layer independence — When you want the domain completely ignorant of persistence
•Complex reconstitution — When loading an entity requires assembling multiple related objects
•Specification pattern usage — When you want domain-expressed query conditions

decision-examples.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
// ═══════════════════════════════════════════════════════════
// SCENARIO 1: Simple Admin Dashboard - DAO is appropriate
// ═══════════════════════════════════════════════════════════
 
// Simple CRUD operations, thin business logic
// DAO maps cleanly to the domain needs
 
interface ProductDAO {
    findAll(page: number, size: number): Promise<ProductDTO[]>;
    findById(id: string): Promise<ProductDTO | null>;
    insert(product: ProductDTO): Promise<string>;
    update(product: ProductDTO): Promise<void>;
    delete(id: string): Promise<void>;
}
 
class ProductController {
    constructor(private readonly productDAO: ProductDAO) {}
    
    async listProducts(page: number, size: number) {
        return this.productDAO.findAll(page, size);
    }
    
    async updateProduct(id: string, updates: Partial<ProductDTO>) {
        const existing = await this.productDAO.findById(id);
        if (!existing) throw new NotFoundError();
        await this.productDAO.update({ ...existing, ...updates });
    }
}
 
 
// ═══════════════════════════════════════════════════════════
// SCENARIO 2: E-Commerce Order System - Repository is appropriate
// ═══════════════════════════════════════════════════════════
 
// Rich domain model with complex aggregates
// Order is an aggregate root containing line items, payments, shipping
 
interface OrderRepository {
    findById(orderId: OrderId): Promise<Order | null>;
    findByCustomer(customerId: CustomerId): Promise<Order[]>;
    save(order: Order): Promise<void>;
}
 
// Rich domain aggregate
class Order {
    private items: OrderLineItem[] = [];
    private payments: Payment[] = [];
    private shipment: Shipment | null = null;
    
    addItem(product: Product, quantity: number): void {
        if (this.status !== OrderStatus.DRAFT) {
            throw new CannotModifySubmittedOrder();
        }
        const item = OrderLineItem.create(product, quantity);
        this.items.push(item);
        this.recalculateTotals();
    }
    
    applyPayment(payment: Payment): void {
        if (this.payments.some(p => p.id.equals(payment.id))) {
            throw new DuplicatePayment();
        }
        this.payments.push(payment);
        if (this.isPaidInFull()) {
            this.transitionTo(OrderStatus.READY_FOR_FULFILLMENT);
        }
    }
    
    // Complex reconstitution requires Repository pattern
    static reconstitute(
        state: OrderState,
        items: OrderLineItem[],
        payments: Payment[],
        shipment: Shipment | null
    ): Order {
        const order = new Order();
        Object.assign(order, state);
        order.items = items;
        order.payments = payments;
        order.shipment = shipment;
        return order;
    }
}
 
// Use case relies on Repository for aggregate integrity
class SubmitOrderUseCase {
    constructor(
        private readonly orderRepository: OrderRepository,
        private readonly inventoryService: InventoryService
    ) {}
    
    async execute(command: SubmitOrderCommand): Promise<void> {
        const order = await this.orderRepository.findById(
            new OrderId(command.orderId)
        );
        
        if (!order) throw new OrderNotFound();
        
        // Check inventory for complete aggregate
        for (const item of order.items) {
            await this.inventoryService.reserve(item.productId, item.quantity);
        }
        
        order.submit();  // Domain behavior
        
        await this.orderRepository.save(order);  // Persists complete aggregate
    }
}

Hybrid Approaches

In sophisticated systems, you might use both patterns together, each serving its appropriate context.

Repository Implemented Using DAOs:

hybrid-approach.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
// ─────────────────────────────────────────────────────────
// HYBRID: Repository uses DAOs internally
// ─────────────────────────────────────────────────────────
 
// DAOs handle table-level access
interface OrderDAO {
    selectById(id: string): Promise<OrderRow | null>;
    insert(row: OrderRow): Promise<void>;
    update(row: OrderRow): Promise<void>;
}
 
interface OrderLineItemDAO {
    selectByOrderId(orderId: string): Promise<OrderLineItemRow[]>;
    insertBatch(items: OrderLineItemRow[]): Promise<void>;
    deleteByOrderId(orderId: string): Promise<void>;
}
 
interface PaymentDAO {
    selectByOrderId(orderId: string): Promise<PaymentRow[]>;
    insert(row: PaymentRow): Promise<void>;
}
 
// Repository coordinates DAOs to manage the aggregate
class PostgresOrderRepository implements OrderRepository {
    constructor(
        private readonly orderDAO: OrderDAO,
        private readonly lineItemDAO: OrderLineItemDAO,
        private readonly paymentDAO: PaymentDAO,
        private readonly aggregateMapper: OrderAggregateMapper
    ) {}
    
    async findById(orderId: OrderId): Promise<Order | null> {
        // Coordinate multiple DAOs to load complete aggregate
        const orderRow = await this.orderDAO.selectById(orderId.value);
        if (!orderRow) return null;
        
        const lineItemRows = await this.lineItemDAO.selectByOrderId(orderId.value);
        const paymentRows = await this.paymentDAO.selectByOrderId(orderId.value);
        
        // Use mapper to reconstitute the aggregate
        return this.aggregateMapper.toDomain(orderRow, lineItemRows, paymentRows);
    }
    
    async save(order: Order): Promise<void> {
        // Coordinate DAOs to persist complete aggregate
        const { orderRow, lineItemRows, paymentRows } = 
            this.aggregateMapper.toRows(order);
        
        // Transaction-aware persistence
        await this.runInTransaction(async () => {
            await this.orderDAO.update(orderRow);
            
            // Replace line items (simplest approach)
            await this.lineItemDAO.deleteByOrderId(order.id.value);
            await this.lineItemDAO.insertBatch(lineItemRows);
            
            // Only insert new payments
            for (const payment of order.newPayments) {
                await this.paymentDAO.insert(
                    this.aggregateMapper.paymentToRow(payment)
                );
            }
        });
    }
}
 
// ─────────────────────────────────────────────────────────
// Benefits of this approach:
// - DAOs remain simple, table-focused, reusable
// - Repository handles aggregate complexity
// - Mapping logic is centralized
// - Each layer has clear responsibility
// ─────────────────────────────────────────────────────────

Layered Abstractions

Summary: DAO vs Repository

Let's consolidate the essential distinctions between DAO and Repository patterns:

DAO vs Repository Summary
Dimension	DAO Pattern	Repository Pattern
Origin	Core J2EE Patterns	Domain-Driven Design
Mental Model	Database abstraction layer	In-memory collection of aggregates
Focus	Technical (table/data access)	Domain (aggregate management)
Granularity	Table-oriented	Aggregate-oriented
Interface Location	Infrastructure layer	Domain layer
Returns	DTOs or simple entities	Rich domain aggregates
Query Language	Technical (offset, limit)	Domain (specifications)
Best For	CRUD apps, data-centric systems	DDD, complex domain models

Key Takeaways

•Different origins, different goals — DAO abstracts database mechanics; Repository abstracts aggregate persistence.
•Interface placement matters — Repository interfaces belong in the domain; DAO interfaces in infrastructure.
•Aggregates vs tables — Repository works with complete aggregates; DAO works with table rows.
•Practical overlap exists — In simple apps, the patterns converge; distinction matters for rich domains.
•Hybrid approaches work — Repository can coordinate DAOs for complex aggregate persistence.
•Choose based on context — CRUD apps favor DAO; DDD systems require Repository.

What's Next:

Page Complete