System Design (LLD)Data Access Object (DAO) Pattern

Data Access Object (DAO) Pattern

LevelIntermediate

Duration60 mins

TopicData Access Object (DAO) Pattern

4 / 4

When to Use DAO

The Architecture Decision

Knowing how to implement a pattern is only half the battle; knowing when to apply it—and when not to—requires mature architectural judgment. The DAO pattern isn't universally optimal. In some contexts, it's essential infrastructure; in others, it's unnecessary ceremony that adds complexity without proportional benefit.

This page develops your judgment for when DAO is the right abstraction, when simpler approaches suffice, and when more sophisticated patterns like Repository are warranted. By the end, you'll have a decision framework for persistence layer design.

What You Will Learn

This page provides decision guidance for persistence layer design. You'll learn the contexts where DAO excels, where alternatives like direct ORM access or the Repository pattern are preferable, and how to evolve your persistence strategy as systems grow.

Context Drives Decisions

Architecture patterns exist to solve problems. The DAO pattern solves specific problems related to data access abstraction, testability, and database independence. If your context doesn't have these problems—or has them to a lesser degree—the pattern's overhead may not be justified.

The Core Trade-Off:

DAO introduces a layer of indirection. This indirection provides benefits (abstraction, testability, flexibility) but costs something (more code, more files, more concepts to understand). The question is whether the benefits outweigh the costs in your specific situation.

DAO Trade-Off Analysis
Benefit	Cost	When Benefit Dominates	When Cost Dominates
Database Independence	Extra abstraction layer	Multiple storage backends anticipated	Single database, no migration planned
Testability (mocking)	Interface + implementation	Complex business logic requiring unit tests	Simple CRUD with integration-only testing
Centralized data access	DAO classes to maintain	Many places access same entities	Few access points, simple data flows
Query encapsulation	Query logic in separate layer	Complex queries, optimization needed	Simple queries, ORM generates adequately

No Universally Correct Answer

Pattern selection is never black and white. The same team might use DAO for critical aggregates while using direct ORM access for simpler entities. Context-sensitivity is the hallmark of mature architecture.

When DAO Is Strongly Indicated

Certain contexts make DAO clearly beneficial—the costs are easily justified by substantial gains. Recognize these patterns in your projects:

DAO-Favorable Contexts

•Multiple database technologies — If you access SQL, NoSQL, external APIs, and file storage, DAOs provide uniform interfaces across heterogeneous backends.
•Legacy system integration — When wrapping legacy databases or external systems, DAOs hide the messiness of old schemas and protocols.
•Database migration planned — If you're likely to switch databases (e.g., migrating from Oracle to PostgreSQL), DAOs make the switch surgical rather than systemic.
•Extensive unit testing requirements — When business logic is complex and requires thorough unit testing, mock DAOs enable fast, reliable tests.
•Query optimization is ongoing — When you need to tune queries without touching business logic, DAOs isolate that optimization work.
•Multiple applications share data access logic — Libraries of DAOs can be shared across microservices or applications.
•Team has mixed database expertise — DAOs let SQL experts optimize queries while other developers work with domain interfaces.

multi-backend-dao.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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
// ═══════════════════════════════════════════════════════════
// EXAMPLE: DAO for Multiple Backends
// ═══════════════════════════════════════════════════════════
 
// Same interface, radically different implementations
 
interface ProductDAO {
    findById(id: string): Promise<Product | null>;
    findByCategory(categoryId: string): Promise<Product[]>;
    save(product: Product): Promise<Product>;
    delete(id: string): Promise<void>;
}
 
// PostgreSQL implementation for core product catalog
class PostgresProductDAO implements ProductDAO {
    constructor(private readonly pool: Pool) {}
    
    async findById(id: string): Promise<Product | null> {
        const result = await this.pool.query(
            'SELECT * FROM products WHERE id = $1',
            [id]
        );
        return result.rows[0] ? this.mapToProduct(result.rows[0]) : null;
    }
    
    async findByCategory(categoryId: string): Promise<Product[]> {
        const result = await this.pool.query(
            `SELECT p.* FROM products p
             JOIN product_categories pc ON p.id = pc.product_id
             WHERE pc.category_id = $1`,
            [categoryId]
        );
        return result.rows.map(row => this.mapToProduct(row));
    }
    
    // ...
}
 
// Elasticsearch implementation for search-optimized reads
class ElasticsearchProductDAO implements ProductDAO {
    constructor(private readonly esClient: ElasticsearchClient) {}
    
    async findById(id: string): Promise<Product | null> {
        try {
            const doc = await this.esClient.get({
                index: 'products',
                id,
            });
            return this.mapToProduct(doc._source);
        } catch (e) {
            if (e.meta?.statusCode === 404) return null;
            throw e;
        }
    }
    
    async findByCategory(categoryId: string): Promise<Product[]> {
        const result = await this.esClient.search({
            index: 'products',
            body: {
                query: {
                    term: { 'categories.id': categoryId }
                }
            }
        });
        return result.hits.hits.map(hit => this.mapToProduct(hit._source));
    }
    
    // ...
}
 
// External API implementation for supplier products
class SupplierApiProductDAO implements ProductDAO {
    constructor(
        private readonly httpClient: HttpClient,
        private readonly supplierConfig: SupplierConfig
    ) {}
    
    async findById(id: string): Promise<Product | null> {
        const response = await this.httpClient.get(
            `${this.supplierConfig.baseUrl}/products/${id}`,
            { headers: { 'Authorization': this.supplierConfig.apiKey }}
        );
        
        if (response.status === 404) return null;
        return this.mapToProduct(response.data);
    }
    
    // ...
}
 
// ─────────────────────────────────────────────────────────
// COMPOSITION: Combining multiple sources
// ─────────────────────────────────────────────────────────
 
class CompositeProductDAO implements ProductDAO {
    constructor(
        private readonly primaryDAO: PostgresProductDAO,
        private readonly searchDAO: ElasticsearchProductDAO,
        private readonly supplierDAO: SupplierApiProductDAO
    ) {}
    
    async findById(id: string): Promise<Product | null> {
        // Try primary first
        const product = await this.primaryDAO.findById(id);
        if (product) return product;
        
        // Fall back to supplier for external products
        return this.supplierDAO.findById(id);
    }
    
    async findByCategory(categoryId: string): Promise<Product[]> {
        // Use search for category browsing (optimized for this use case)
        return this.searchDAO.findByCategory(categoryId);
    }
    
    // Writes go to primary, then sync to search
    async save(product: Product): Promise<Product> {
        const saved = await this.primaryDAO.save(product);
        await this.searchDAO.save(saved);  // Keep search index in sync
        return saved;
    }
}

Multi-Backend Power

The ability to compose DAOs from multiple backends—while presenting a uniform interface to the business layer—is one of DAO's most powerful capabilities. The business layer doesn't know or care that products come from PostgreSQL, Elasticsearch, or external APIs.

When DAO is Unnecessary Overhead

Some contexts don't need the abstraction DAO provides. In these situations, DAO adds ceremony without corresponding value:

Contexts Where DAO Is Overhead

•Small, simple applications — A startup MVP with 5 entities and straightforward CRUD rarely needs DAO abstraction. Direct ORM use is simpler.
•Tight ORM coupling is acceptable — If you're committed to a specific ORM (e.g., Prisma, TypeORM) and unlikely to switch, the ORM's native patterns may suffice.
•Rapid prototyping — When velocity matters more than architecture, skip DAOs initially. They can be introduced later if needed.
•Single developer, small team — DAO's separation value increases with team size. Solo developers often find direct access faster.
•No unit testing of business logic — If you only write integration tests anyway, mock-able DAOs have less value.
•ORM provides adequate abstraction — Modern ORMs like Prisma or Entity Framework already abstract database details significantly.

direct-orm-example.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
// ═══════════════════════════════════════════════════════════
// EXAMPLE: Direct ORM Use (No DAO Layer)
// For simple applications where DAO would be overkill
// ═══════════════════════════════════════════════════════════
 
 
 
 
// Service directly uses ORM - no intermediate DAO layer
class UserService {
    async createUser(dto: CreateUserDTO): Promise<UserResponse> {
        // Direct Prisma usage
        const user = await prisma.user.create({
            data: {
                email: dto.email,
                name: dto.name,
                status: 'ACTIVE',
            },
        });
        
        return this.toResponse(user);
    }
    
    async findById(id: string): Promise<UserResponse | null> {
        const user = await prisma.user.findUnique({
            where: { id },
            include: { preferences: true },  // ORM handles joins
        });
        
        return user ? this.toResponse(user) : null;
    }
    
    async updateUser(id: string, dto: UpdateUserDTO): Promise<UserResponse> {
        const user = await prisma.user.update({
            where: { id },
            data: {
                name: dto.name,
                updatedAt: new Date(),
            },
        });
        
        return this.toResponse(user);
    }
    
    private toResponse(user: any): UserResponse {
        return {
            id: user.id,
            email: user.email,
            name: user.name,
            status: user.status,
        };
    }
}
 
// ─────────────────────────────────────────────────────────
// THIS APPROACH WORKS WHEN:
// - Application is simple (few entities, straightforward logic)
// - ORM is unlikely to change
// - Team is comfortable with ORM patterns
// - Integration testing is the primary testing strategy
// - Fast iteration is prioritized over architectural purity
// ─────────────────────────────────────────────────────────
 
// ─────────────────────────────────────────────────────────
// THIS APPROACH BECOMES PROBLEMATIC WHEN:
// - Business logic becomes complex enough to require unit testing
// - Multiple services need to access the same entities differently
// - Query optimization requires centralization
// - Database migration becomes necessary
// - Team grows and needs clearer architectural boundaries
// ─────────────────────────────────────────────────────────

YAGNI Applies

You Aren't Gonna Need It (YAGNI) applies to architecture patterns too. Don't add DAOs 'just in case' you might switch databases. Add them when you have concrete evidence of the problems they solve—or when the codebase has grown enough that the abstraction clearly helps.

When Repository Is Preferred Over DAO

As discussed in the DAO vs Repository comparison, these patterns serve different purposes. Some contexts favor Repository over DAO:

Repository-Preferred Contexts

•Domain-Driven Design adoption — If you're practicing DDD with aggregates, entities, and value objects, Repository is the natural persistence pattern.
•Rich domain model — When entities have significant behavior and invariants, Repository ensures aggregates are reconstituted correctly.
•Aggregate-oriented persistence — When your unit of persistence is a cluster of objects (aggregate), not individual tables.
•Domain layer independence — When maintaining the domain layer free of infrastructure dependencies is a priority.
•Specification pattern usage — When you want to express queries in domain terms using the Specification pattern.

repository-vs-dao-decision.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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
// ═══════════════════════════════════════════════════════════
// DECISION EXAMPLE: DAO vs Repository
// ═══════════════════════════════════════════════════════════
 
// ─────────────────────────────────────────────────────────
// SCENARIO A: Simple Blog Platform
// Choose: DAO (or direct ORM)
// Reason: Simple CRUD, no complex domain logic
// ─────────────────────────────────────────────────────────
 
// Entity is basically a data structure
interface BlogPost {
    id: string;
    title: string;
    content: string;
    authorId: string;
    publishedAt: Date | null;
    createdAt: Date;
    updatedAt: Date;
}
 
// DAO maps directly to table operations
interface BlogPostDAO {
    insert(post: BlogPost): Promise<BlogPost>;
    update(post: BlogPost): Promise<BlogPost>;
    delete(id: string): Promise<void>;
    findById(id: string): Promise<BlogPost | null>;
    findByAuthor(authorId: string): Promise<BlogPost[]>;
    findPublished(page: number, pageSize: number): Promise<BlogPost[]>;
}
 
// ─────────────────────────────────────────────────────────
// SCENARIO B: E-Commerce Order System
// Choose: Repository
// Reason: Rich domain model, complex aggregates, business rules
// ─────────────────────────────────────────────────────────
 
// Rich domain aggregate with behavior and invariants
class Order {
    private _items: OrderLineItem[] = [];
    private _status: OrderStatus = OrderStatus.DRAFT;
    private _payments: Payment[] = [];
    
    // Business rules encapsulated
    addItem(product: Product, quantity: number): void {
        if (this._status !== OrderStatus.DRAFT) {
            throw new CannotModifySubmittedOrder();
        }
        if (quantity <= 0) {
            throw new InvalidQuantity();
        }
        
        const existingItem = this._items.find(
            item => item.productId.equals(product.id)
        );
        
        if (existingItem) {
            existingItem.increaseQuantity(quantity);
        } else {
            this._items.push(OrderLineItem.create(product, quantity));
        }
        
        this.recordEvent(new ItemAddedToOrder(this.id, product.id, quantity));
    }
    
    submit(): void {
        if (this._items.length === 0) {
            throw new CannotSubmitEmptyOrder();
        }
        if (this._status !== OrderStatus.DRAFT) {
            throw new OrderAlreadySubmitted();
        }
        
        this._status = OrderStatus.SUBMITTED;
        this.recordEvent(new OrderSubmitted(this.id));
    }
    
    // Complex state that must be persisted together
    get totalAmount(): Money {
        return this._items.reduce(
            (sum, item) => sum.add(item.totalPrice),
            Money.zero()
        );
    }
}
 
// Repository handles aggregate persistence
interface OrderRepository {
    // Collection semantics
    add(order: Order): Promise<void>;
    save(order: Order): Promise<void>;
    remove(order: Order): Promise<void>;
    
    // Domain-typed queries
    findById(id: OrderId): Promise<Order | null>;
    
    // Domain-meaningful operations
    findPendingOrdersForCustomer(customerId: CustomerId): Promise<Order[]>;
    findOrdersRequiringFulfillment(): Promise<Order[]>;
}
 
// ─────────────────────────────────────────────────────────
// DECISION FRAMEWORK
// ─────────────────────────────────────────────────────────
 
/*
Question 1: Do you have aggregates (clusters of objects treated as a unit)?
  - Yes → Consider Repository
  - No  → DAO or direct ORM is fine
 
Question 2: Does your domain have significant business rules?
  - Yes → Repository helps keep domain clean
  - No  → DAO provides sufficient abstraction
 
Question 3: Is domain layer independence a priority?
  - Yes → Repository (interface in domain, impl in infrastructure)
  - No  → DAO (both in infrastructure)
 
Question 4: Are you practicing DDD?
  - Yes → Repository is the standard pattern
  - No  → Either pattern works; choose based on other factors
*/

Hybrid and Evolutionary Strategies

Real systems rarely fit neatly into one pattern. Sophisticated architectures often combine approaches, applying different patterns to different parts of the system, and evolving the persistence strategy as the system matures.

Strategy 1: Pattern Per Context

Different bounded contexts or modules may warrant different approaches. A single application might use:

Repository for the core ordering domain (rich, complex)
DAO for the reporting module (query-focused, read-heavy)
Direct ORM for admin CRUD screens (simple, low-risk)

hybrid-strategy.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
// ═══════════════════════════════════════════════════════════
// HYBRID STRATEGY: Different patterns for different contexts
// ═══════════════════════════════════════════════════════════
 
// ─────────────────────────────────────────────────────────
// ORDERING CONTEXT: Repository Pattern (Rich Domain)
// ─────────────────────────────────────────────────────────
 
// domain/ordering/repositories/order-repository.ts
interface OrderRepository {
    findById(id: OrderId): Promise<Order | null>;
    save(order: Order): Promise<void>;
    findPendingOrders(): Promise<Order[]>;
}
 
// infrastructure/persistence/ordering/...
class PostgresOrderRepository implements OrderRepository {
    // Complex aggregate reconstitution
    async findById(id: OrderId): Promise<Order | null> {
        const orderData = await this.loadOrderWithRelations(id);
        if (!orderData) return null;
        return Order.reconstitute(orderData);
    }
}
 
// ─────────────────────────────────────────────────────────
// REPORTING CONTEXT: DAO Pattern (Query-Focused)
// ─────────────────────────────────────────────────────────
 
// infrastructure/reporting/sales-report-dao.ts
interface SalesReportDAO {
    getDailySalesSummary(date: Date): Promise<DailySalesSummary>;
    getMonthlySalesByCategory(
        year: number, 
        month: number
    ): Promise<CategorySalesReport[]>;
    getTopSellingProducts(
        period: DateRange, 
        limit: number
    ): Promise<TopProductReport[]>;
}
 
class PostgresSalesReportDAO implements SalesReportDAO {
    // Complex reporting queries optimized for read performance
    async getDailySalesSummary(date: Date): Promise<DailySalesSummary> {
        const result = await this.pool.query(`
            SELECT 
                COUNT(*) as order_count,
                SUM(total_amount) as total_revenue,
                AVG(total_amount) as average_order_value,
                COUNT(DISTINCT customer_id) as unique_customers
            FROM orders
            WHERE DATE(created_at) = $1
            AND status IN ('COMPLETED', 'SHIPPED')
        `, [date]);
        
        return this.mapToSummary(result.rows[0]);
    }
}
 
// ─────────────────────────────────────────────────────────
// ADMIN CONTEXT: Direct ORM (Simple CRUD)
// ─────────────────────────────────────────────────────────
 
// admin/services/category-admin-service.ts
class CategoryAdminService {
    constructor(private readonly prisma: PrismaClient) {}
    
    // Simple CRUD - no need for abstraction
    async listCategories(): Promise<Category[]> {
        return this.prisma.category.findMany({
            orderBy: { name: 'asc' },
        });
    }
    
    async createCategory(dto: CreateCategoryDTO): Promise<Category> {
        return this.prisma.category.create({
            data: {
                name: dto.name,
                description: dto.description,
                parentId: dto.parentId,
            },
        });
    }
    
    async updateCategory(id: string, dto: UpdateCategoryDTO): Promise<Category> {
        return this.prisma.category.update({
            where: { id },
            data: dto,
        });
    }
}

Strategy 2: Evolutionary Introduction

Start simple and introduce patterns as complexity warrants. This approach respects YAGNI while remaining open to evolution:

Evolutionary Pattern Introduction
Application Stage	Typical Approach	Trigger for Evolution
Prototype / MVP	Direct ORM; no abstraction layer	Code duplication; testing difficulties
Growing Product	Introduce DAOs for heavily-accessed entities	Complex domain logic; scaling needs
Mature Product	Repository for core domains; DAO for data access	DDD adoption; aggregate identification
Enterprise Scale	Full pattern library; context-specific choices	Team growth; multi-team boundaries

evolutionary-pattern.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
// ═══════════════════════════════════════════════════════════
// EVOLUTIONARY PATTERN: Start Simple, Add Abstraction as Needed
// ═══════════════════════════════════════════════════════════
 
// ─────────────────────────────────────────────────────────
// STAGE 1: Direct ORM (Initial Development)
// ─────────────────────────────────────────────────────────
 
class OrderServiceV1 {
    async createOrder(dto: CreateOrderDTO): Promise<Order> {
        // Direct Prisma usage
        return prisma.order.create({
            data: {
                customerId: dto.customerId,
                items: {
                    create: dto.items.map(item => ({
                        productId: item.productId,
                        quantity: item.quantity,
                        unitPrice: item.unitPrice,
                    })),
                },
            },
            include: { items: true },
        });
    }
}
 
// ─────────────────────────────────────────────────────────
// STAGE 2: Extract DAO (Growing Complexity)
// Trigger: Multiple services need order access; testing is difficult
// ─────────────────────────────────────────────────────────
 
interface OrderDAO {
    findById(id: string): Promise<Order | null>;
    findByCustomer(customerId: string): Promise<Order[]>;
    create(order: CreateOrderData): Promise<Order>;
    update(order: Order): Promise<Order>;
}
 
class PrismaOrderDAO implements OrderDAO {
    // Centralized data access logic
    async findById(id: string): Promise<Order | null> {
        return prisma.order.findUnique({
            where: { id },
            include: { items: true, payments: true },
        });
    }
    // ...
}
 
class OrderServiceV2 {
    constructor(private readonly orderDAO: OrderDAO) {}
    
    async createOrder(dto: CreateOrderDTO): Promise<Order> {
        // Now uses injected DAO - testable!
        return this.orderDAO.create(dto);
    }
}
 
// ─────────────────────────────────────────────────────────
// STAGE 3: Repository for Core Aggregates (Domain Maturity)
// Trigger: Rich domain logic; aggregate invariants identified
// ─────────────────────────────────────────────────────────
 
// Domain layer (clean, no infrastructure dependencies)
class Order {
    // Rich behavior
    addItem(product: Product, quantity: number): void { /* ... */ }
    submit(): void { /* ... */ }
    applyPayment(payment: Payment): void { /* ... */ }
}
 
interface OrderRepository {
    findById(id: OrderId): Promise<Order | null>;
    save(order: Order): Promise<void>;
}
 
// Infrastructure layer implements repository
class PostgresOrderRepository implements OrderRepository {
    async save(order: Order): Promise<void> {
        // Complex aggregate persistence
        // Might use internal DAOs for table-level operations
    }
}
 
// Application layer orchestrates
class CreateOrderUseCase {
    constructor(private readonly orderRepository: OrderRepository) {}
    
    async execute(command: CreateOrderCommand): Promise<void> {
        const order = Order.create(command);
        await this.orderRepository.save(order);
    }
}

Refactoring Safety

Introducing DAO or Repository later is a refactoring, not a rewrite. If you have good test coverage (even integration tests), you can introduce the abstraction incrementally without breaking functionality. Start with the most-accessed entities; gradually expand.

Organizational Considerations

Pattern selection isn't purely technical—organizational factors influence the right choice:

Team and Organization Factors

•Team size and structure — Larger teams benefit from clearer boundaries that DAO/Repository provides. Solo developers may find it overhead.
•Team experience — Junior teams may struggle with additional abstraction layers. Senior teams often demand them for maintainability.
•Database expertise distribution — If only some team members know SQL well, DAOs let them optimize queries while others work on business logic.
•Onboarding considerations — Established patterns with clear conventions speed up new developer ramp-up.
•Multi-team boundaries — When multiple teams access shared data, well-defined DAOs/Repositories establish contracts.
•Code ownership — DAOs provide natural seams for ownership (e.g., data platform team owns DAOs, product teams own services).

Team Context Guidelines
Team Characteristic	Pattern Recommendation	Rationale
Solo / 2-3 developers	Direct ORM or minimal DAO	Speed over structure; less ceremony
Small team (4-7)	DAO for shared entities	Balance pragmatism and structure
Medium team (8-15)	DAO layer + Repository for complex aggregates	Clear boundaries; testability
Large / multi-team	Full pattern library; enforced standards	Coordination; contract definition

Conway's Law

System architecture tends to mirror organizational structure. If separate teams own the database layer and business layer, an explicit DAO interface becomes a natural contract point. Design patterns should align with how your organization actually works.

The DAO Decision Framework

Synthesizing the considerations above, here's a practical decision framework:

decision-framework.txt
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
┌─────────────────────────────────────────────────────────┐
│           DAO PATTERN DECISION FRAMEWORK                 │
└─────────────────────────────────────────────────────────┘
 
START: Do you need database abstraction?
        │
        ├─ Multiple storage backends? ─────────────────┐
        │       │                                      │
        │       └─ YES ───────────────────► USE DAO ◄──┘
        │       │
        │       └─ NO ──────────────┐
        │                           ▼
        ├─ Database migration planned? ─────────────────┐
        │       │                                       │
        │       └─ YES ──────────────────► USE DAO ◄────┘
        │       │
        │       └─ NO ──────────────┐
        │                           ▼
        └─ Complex unit testing needs? ─────────────────┐
                │                                       │
                └─ YES ──────────────────► USE DAO ◄────┘
                │
                └─ NO ──────────────┐
                                    ▼
        Do you have a rich domain model?
                │
                ├─ YES + practicing DDD ──► USE REPOSITORY
                │
                ├─ YES + not DDD ─────────► USE DAO (or Repository)
                │
                └─ NO ───────────────┐
                                     ▼
        Is this a simple CRUD application?
                │
                ├─ YES ───────────────────► USE DIRECT ORM
                │
                └─ NO ────────────────────► USE DAO
 
┌─────────────────────────────────────────────────────────┐
│           SIGNALS TO INTRODUCE DAO LATER                 │
└─────────────────────────────────────────────────────────┘
 
• Same queries duplicated in 3+ places
• Test setup requires database for business logic tests
• Query optimization needed without changing services
• Team growing; need clearer architectural boundaries
• Database performance debugging is difficult
• Multiple services access same data differently

Start Conservative

When in doubt, start without DAO and add it when you feel the pain of not having it. Adding abstraction is easier than removing unnecessary abstraction. Real pain teaches better than theoretical benefits.

Summary: When to Use DAO

Let's consolidate the decision guidance covered in this module:

Key Takeaways

•Context determines pattern choice — DAO solves specific problems; verify you have those problems before applying the pattern.
•DAO shines with multiple backends — When you access heterogeneous storage, DAO's uniform interface is invaluable.
•Skip DAO for simple CRUD — Small applications with straightforward data access don't need the abstraction.
•Choose Repository for DDD — When practicing Domain-Driven Design with rich aggregates, Repository is the natural pattern.
•Hybrid strategies work — Different parts of your system can use different patterns based on their complexity.
•Evolution is valid — Start simple; introduce patterns when complexity warrants them.
•Consider the team — Pattern selection should account for team size, experience, and organizational structure.

Module Complete:

You've now completed the comprehensive exploration of the Data Access Object pattern—from its definition and purpose, through its distinction from Repository, into practical implementation, and finally to decision guidance. You possess the knowledge to apply DAO appropriately and implement it effectively.

Module Complete

Congratulations! You now have comprehensive knowledge of the DAO pattern—when to use it, how to implement it, and how it relates to other persistence patterns. This knowledge enables you to make informed architectural decisions about data access in your systems.

4 / 4

Loading learning content...

System Design (LLD)Data Access Object (DAO) Pattern

Data Access Object (DAO) Pattern

LevelIntermediate

Duration60 mins

TopicData Access Object (DAO) Pattern

4 / 4

When to Use DAO

The Architecture Decision

What You Will Learn

Context Drives Decisions

The Core Trade-Off:

DAO Trade-Off Analysis
Benefit	Cost	When Benefit Dominates	When Cost Dominates
Database Independence	Extra abstraction layer	Multiple storage backends anticipated	Single database, no migration planned
Testability (mocking)	Interface + implementation	Complex business logic requiring unit tests	Simple CRUD with integration-only testing
Centralized data access	DAO classes to maintain	Many places access same entities	Few access points, simple data flows
Query encapsulation	Query logic in separate layer	Complex queries, optimization needed	Simple queries, ORM generates adequately

No Universally Correct Answer

When DAO Is Strongly Indicated

Certain contexts make DAO clearly beneficial—the costs are easily justified by substantial gains. Recognize these patterns in your projects:

DAO-Favorable Contexts

•Multiple database technologies — If you access SQL, NoSQL, external APIs, and file storage, DAOs provide uniform interfaces across heterogeneous backends.
•Legacy system integration — When wrapping legacy databases or external systems, DAOs hide the messiness of old schemas and protocols.
•Database migration planned — If you're likely to switch databases (e.g., migrating from Oracle to PostgreSQL), DAOs make the switch surgical rather than systemic.
•Extensive unit testing requirements — When business logic is complex and requires thorough unit testing, mock DAOs enable fast, reliable tests.
•Query optimization is ongoing — When you need to tune queries without touching business logic, DAOs isolate that optimization work.
•Multiple applications share data access logic — Libraries of DAOs can be shared across microservices or applications.
•Team has mixed database expertise — DAOs let SQL experts optimize queries while other developers work with domain interfaces.

multi-backend-dao.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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
// ═══════════════════════════════════════════════════════════
// EXAMPLE: DAO for Multiple Backends
// ═══════════════════════════════════════════════════════════
 
// Same interface, radically different implementations
 
interface ProductDAO {
    findById(id: string): Promise<Product | null>;
    findByCategory(categoryId: string): Promise<Product[]>;
    save(product: Product): Promise<Product>;
    delete(id: string): Promise<void>;
}
 
// PostgreSQL implementation for core product catalog
class PostgresProductDAO implements ProductDAO {
    constructor(private readonly pool: Pool) {}
    
    async findById(id: string): Promise<Product | null> {
        const result = await this.pool.query(
            'SELECT * FROM products WHERE id = $1',
            [id]
        );
        return result.rows[0] ? this.mapToProduct(result.rows[0]) : null;
    }
    
    async findByCategory(categoryId: string): Promise<Product[]> {
        const result = await this.pool.query(
            `SELECT p.* FROM products p
             JOIN product_categories pc ON p.id = pc.product_id
             WHERE pc.category_id = $1`,
            [categoryId]
        );
        return result.rows.map(row => this.mapToProduct(row));
    }
    
    // ...
}
 
// Elasticsearch implementation for search-optimized reads
class ElasticsearchProductDAO implements ProductDAO {
    constructor(private readonly esClient: ElasticsearchClient) {}
    
    async findById(id: string): Promise<Product | null> {
        try {
            const doc = await this.esClient.get({
                index: 'products',
                id,
            });
            return this.mapToProduct(doc._source);
        } catch (e) {
            if (e.meta?.statusCode === 404) return null;
            throw e;
        }
    }
    
    async findByCategory(categoryId: string): Promise<Product[]> {
        const result = await this.esClient.search({
            index: 'products',
            body: {
                query: {
                    term: { 'categories.id': categoryId }
                }
            }
        });
        return result.hits.hits.map(hit => this.mapToProduct(hit._source));
    }
    
    // ...
}
 
// External API implementation for supplier products
class SupplierApiProductDAO implements ProductDAO {
    constructor(
        private readonly httpClient: HttpClient,
        private readonly supplierConfig: SupplierConfig
    ) {}
    
    async findById(id: string): Promise<Product | null> {
        const response = await this.httpClient.get(
            `${this.supplierConfig.baseUrl}/products/${id}`,
            { headers: { 'Authorization': this.supplierConfig.apiKey }}
        );
        
        if (response.status === 404) return null;
        return this.mapToProduct(response.data);
    }
    
    // ...
}
 
// ─────────────────────────────────────────────────────────
// COMPOSITION: Combining multiple sources
// ─────────────────────────────────────────────────────────
 
class CompositeProductDAO implements ProductDAO {
    constructor(
        private readonly primaryDAO: PostgresProductDAO,
        private readonly searchDAO: ElasticsearchProductDAO,
        private readonly supplierDAO: SupplierApiProductDAO
    ) {}
    
    async findById(id: string): Promise<Product | null> {
        // Try primary first
        const product = await this.primaryDAO.findById(id);
        if (product) return product;
        
        // Fall back to supplier for external products
        return this.supplierDAO.findById(id);
    }
    
    async findByCategory(categoryId: string): Promise<Product[]> {
        // Use search for category browsing (optimized for this use case)
        return this.searchDAO.findByCategory(categoryId);
    }
    
    // Writes go to primary, then sync to search
    async save(product: Product): Promise<Product> {
        const saved = await this.primaryDAO.save(product);
        await this.searchDAO.save(saved);  // Keep search index in sync
        return saved;
    }
}

Multi-Backend Power

When DAO is Unnecessary Overhead

Some contexts don't need the abstraction DAO provides. In these situations, DAO adds ceremony without corresponding value:

Contexts Where DAO Is Overhead

•Small, simple applications — A startup MVP with 5 entities and straightforward CRUD rarely needs DAO abstraction. Direct ORM use is simpler.
•Tight ORM coupling is acceptable — If you're committed to a specific ORM (e.g., Prisma, TypeORM) and unlikely to switch, the ORM's native patterns may suffice.
•Rapid prototyping — When velocity matters more than architecture, skip DAOs initially. They can be introduced later if needed.
•Single developer, small team — DAO's separation value increases with team size. Solo developers often find direct access faster.
•No unit testing of business logic — If you only write integration tests anyway, mock-able DAOs have less value.
•ORM provides adequate abstraction — Modern ORMs like Prisma or Entity Framework already abstract database details significantly.

direct-orm-example.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
// ═══════════════════════════════════════════════════════════
// EXAMPLE: Direct ORM Use (No DAO Layer)
// For simple applications where DAO would be overkill
// ═══════════════════════════════════════════════════════════
 
 
 
 
// Service directly uses ORM - no intermediate DAO layer
class UserService {
    async createUser(dto: CreateUserDTO): Promise<UserResponse> {
        // Direct Prisma usage
        const user = await prisma.user.create({
            data: {
                email: dto.email,
                name: dto.name,
                status: 'ACTIVE',
            },
        });
        
        return this.toResponse(user);
    }
    
    async findById(id: string): Promise<UserResponse | null> {
        const user = await prisma.user.findUnique({
            where: { id },
            include: { preferences: true },  // ORM handles joins
        });
        
        return user ? this.toResponse(user) : null;
    }
    
    async updateUser(id: string, dto: UpdateUserDTO): Promise<UserResponse> {
        const user = await prisma.user.update({
            where: { id },
            data: {
                name: dto.name,
                updatedAt: new Date(),
            },
        });
        
        return this.toResponse(user);
    }
    
    private toResponse(user: any): UserResponse {
        return {
            id: user.id,
            email: user.email,
            name: user.name,
            status: user.status,
        };
    }
}
 
// ─────────────────────────────────────────────────────────
// THIS APPROACH WORKS WHEN:
// - Application is simple (few entities, straightforward logic)
// - ORM is unlikely to change
// - Team is comfortable with ORM patterns
// - Integration testing is the primary testing strategy
// - Fast iteration is prioritized over architectural purity
// ─────────────────────────────────────────────────────────
 
// ─────────────────────────────────────────────────────────
// THIS APPROACH BECOMES PROBLEMATIC WHEN:
// - Business logic becomes complex enough to require unit testing
// - Multiple services need to access the same entities differently
// - Query optimization requires centralization
// - Database migration becomes necessary
// - Team grows and needs clearer architectural boundaries
// ─────────────────────────────────────────────────────────

YAGNI Applies

When Repository Is Preferred Over DAO

As discussed in the DAO vs Repository comparison, these patterns serve different purposes. Some contexts favor Repository over DAO:

Repository-Preferred Contexts

•Domain-Driven Design adoption — If you're practicing DDD with aggregates, entities, and value objects, Repository is the natural persistence pattern.
•Rich domain model — When entities have significant behavior and invariants, Repository ensures aggregates are reconstituted correctly.
•Aggregate-oriented persistence — When your unit of persistence is a cluster of objects (aggregate), not individual tables.
•Domain layer independence — When maintaining the domain layer free of infrastructure dependencies is a priority.
•Specification pattern usage — When you want to express queries in domain terms using the Specification pattern.

repository-vs-dao-decision.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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
// ═══════════════════════════════════════════════════════════
// DECISION EXAMPLE: DAO vs Repository
// ═══════════════════════════════════════════════════════════
 
// ─────────────────────────────────────────────────────────
// SCENARIO A: Simple Blog Platform
// Choose: DAO (or direct ORM)
// Reason: Simple CRUD, no complex domain logic
// ─────────────────────────────────────────────────────────
 
// Entity is basically a data structure
interface BlogPost {
    id: string;
    title: string;
    content: string;
    authorId: string;
    publishedAt: Date | null;
    createdAt: Date;
    updatedAt: Date;
}
 
// DAO maps directly to table operations
interface BlogPostDAO {
    insert(post: BlogPost): Promise<BlogPost>;
    update(post: BlogPost): Promise<BlogPost>;
    delete(id: string): Promise<void>;
    findById(id: string): Promise<BlogPost | null>;
    findByAuthor(authorId: string): Promise<BlogPost[]>;
    findPublished(page: number, pageSize: number): Promise<BlogPost[]>;
}
 
// ─────────────────────────────────────────────────────────
// SCENARIO B: E-Commerce Order System
// Choose: Repository
// Reason: Rich domain model, complex aggregates, business rules
// ─────────────────────────────────────────────────────────
 
// Rich domain aggregate with behavior and invariants
class Order {
    private _items: OrderLineItem[] = [];
    private _status: OrderStatus = OrderStatus.DRAFT;
    private _payments: Payment[] = [];
    
    // Business rules encapsulated
    addItem(product: Product, quantity: number): void {
        if (this._status !== OrderStatus.DRAFT) {
            throw new CannotModifySubmittedOrder();
        }
        if (quantity <= 0) {
            throw new InvalidQuantity();
        }
        
        const existingItem = this._items.find(
            item => item.productId.equals(product.id)
        );
        
        if (existingItem) {
            existingItem.increaseQuantity(quantity);
        } else {
            this._items.push(OrderLineItem.create(product, quantity));
        }
        
        this.recordEvent(new ItemAddedToOrder(this.id, product.id, quantity));
    }
    
    submit(): void {
        if (this._items.length === 0) {
            throw new CannotSubmitEmptyOrder();
        }
        if (this._status !== OrderStatus.DRAFT) {
            throw new OrderAlreadySubmitted();
        }
        
        this._status = OrderStatus.SUBMITTED;
        this.recordEvent(new OrderSubmitted(this.id));
    }
    
    // Complex state that must be persisted together
    get totalAmount(): Money {
        return this._items.reduce(
            (sum, item) => sum.add(item.totalPrice),
            Money.zero()
        );
    }
}
 
// Repository handles aggregate persistence
interface OrderRepository {
    // Collection semantics
    add(order: Order): Promise<void>;
    save(order: Order): Promise<void>;
    remove(order: Order): Promise<void>;
    
    // Domain-typed queries
    findById(id: OrderId): Promise<Order | null>;
    
    // Domain-meaningful operations
    findPendingOrdersForCustomer(customerId: CustomerId): Promise<Order[]>;
    findOrdersRequiringFulfillment(): Promise<Order[]>;
}
 
// ─────────────────────────────────────────────────────────
// DECISION FRAMEWORK
// ─────────────────────────────────────────────────────────
 
/*
Question 1: Do you have aggregates (clusters of objects treated as a unit)?
  - Yes → Consider Repository
  - No  → DAO or direct ORM is fine
 
Question 2: Does your domain have significant business rules?
  - Yes → Repository helps keep domain clean
  - No  → DAO provides sufficient abstraction
 
Question 3: Is domain layer independence a priority?
  - Yes → Repository (interface in domain, impl in infrastructure)
  - No  → DAO (both in infrastructure)
 
Question 4: Are you practicing DDD?
  - Yes → Repository is the standard pattern
  - No  → Either pattern works; choose based on other factors
*/

Hybrid and Evolutionary Strategies

Strategy 1: Pattern Per Context

Different bounded contexts or modules may warrant different approaches. A single application might use:

Repository for the core ordering domain (rich, complex)
DAO for the reporting module (query-focused, read-heavy)
Direct ORM for admin CRUD screens (simple, low-risk)

hybrid-strategy.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
// ═══════════════════════════════════════════════════════════
// HYBRID STRATEGY: Different patterns for different contexts
// ═══════════════════════════════════════════════════════════
 
// ─────────────────────────────────────────────────────────
// ORDERING CONTEXT: Repository Pattern (Rich Domain)
// ─────────────────────────────────────────────────────────
 
// domain/ordering/repositories/order-repository.ts
interface OrderRepository {
    findById(id: OrderId): Promise<Order | null>;
    save(order: Order): Promise<void>;
    findPendingOrders(): Promise<Order[]>;
}
 
// infrastructure/persistence/ordering/...
class PostgresOrderRepository implements OrderRepository {
    // Complex aggregate reconstitution
    async findById(id: OrderId): Promise<Order | null> {
        const orderData = await this.loadOrderWithRelations(id);
        if (!orderData) return null;
        return Order.reconstitute(orderData);
    }
}
 
// ─────────────────────────────────────────────────────────
// REPORTING CONTEXT: DAO Pattern (Query-Focused)
// ─────────────────────────────────────────────────────────
 
// infrastructure/reporting/sales-report-dao.ts
interface SalesReportDAO {
    getDailySalesSummary(date: Date): Promise<DailySalesSummary>;
    getMonthlySalesByCategory(
        year: number, 
        month: number
    ): Promise<CategorySalesReport[]>;
    getTopSellingProducts(
        period: DateRange, 
        limit: number
    ): Promise<TopProductReport[]>;
}
 
class PostgresSalesReportDAO implements SalesReportDAO {
    // Complex reporting queries optimized for read performance
    async getDailySalesSummary(date: Date): Promise<DailySalesSummary> {
        const result = await this.pool.query(`
            SELECT 
                COUNT(*) as order_count,
                SUM(total_amount) as total_revenue,
                AVG(total_amount) as average_order_value,
                COUNT(DISTINCT customer_id) as unique_customers
            FROM orders
            WHERE DATE(created_at) = $1
            AND status IN ('COMPLETED', 'SHIPPED')
        `, [date]);
        
        return this.mapToSummary(result.rows[0]);
    }
}
 
// ─────────────────────────────────────────────────────────
// ADMIN CONTEXT: Direct ORM (Simple CRUD)
// ─────────────────────────────────────────────────────────
 
// admin/services/category-admin-service.ts
class CategoryAdminService {
    constructor(private readonly prisma: PrismaClient) {}
    
    // Simple CRUD - no need for abstraction
    async listCategories(): Promise<Category[]> {
        return this.prisma.category.findMany({
            orderBy: { name: 'asc' },
        });
    }
    
    async createCategory(dto: CreateCategoryDTO): Promise<Category> {
        return this.prisma.category.create({
            data: {
                name: dto.name,
                description: dto.description,
                parentId: dto.parentId,
            },
        });
    }
    
    async updateCategory(id: string, dto: UpdateCategoryDTO): Promise<Category> {
        return this.prisma.category.update({
            where: { id },
            data: dto,
        });
    }
}

Strategy 2: Evolutionary Introduction

Start simple and introduce patterns as complexity warrants. This approach respects YAGNI while remaining open to evolution:

Evolutionary Pattern Introduction
Application Stage	Typical Approach	Trigger for Evolution
Prototype / MVP	Direct ORM; no abstraction layer	Code duplication; testing difficulties
Growing Product	Introduce DAOs for heavily-accessed entities	Complex domain logic; scaling needs
Mature Product	Repository for core domains; DAO for data access	DDD adoption; aggregate identification
Enterprise Scale	Full pattern library; context-specific choices	Team growth; multi-team boundaries

evolutionary-pattern.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
// ═══════════════════════════════════════════════════════════
// EVOLUTIONARY PATTERN: Start Simple, Add Abstraction as Needed
// ═══════════════════════════════════════════════════════════
 
// ─────────────────────────────────────────────────────────
// STAGE 1: Direct ORM (Initial Development)
// ─────────────────────────────────────────────────────────
 
class OrderServiceV1 {
    async createOrder(dto: CreateOrderDTO): Promise<Order> {
        // Direct Prisma usage
        return prisma.order.create({
            data: {
                customerId: dto.customerId,
                items: {
                    create: dto.items.map(item => ({
                        productId: item.productId,
                        quantity: item.quantity,
                        unitPrice: item.unitPrice,
                    })),
                },
            },
            include: { items: true },
        });
    }
}
 
// ─────────────────────────────────────────────────────────
// STAGE 2: Extract DAO (Growing Complexity)
// Trigger: Multiple services need order access; testing is difficult
// ─────────────────────────────────────────────────────────
 
interface OrderDAO {
    findById(id: string): Promise<Order | null>;
    findByCustomer(customerId: string): Promise<Order[]>;
    create(order: CreateOrderData): Promise<Order>;
    update(order: Order): Promise<Order>;
}
 
class PrismaOrderDAO implements OrderDAO {
    // Centralized data access logic
    async findById(id: string): Promise<Order | null> {
        return prisma.order.findUnique({
            where: { id },
            include: { items: true, payments: true },
        });
    }
    // ...
}
 
class OrderServiceV2 {
    constructor(private readonly orderDAO: OrderDAO) {}
    
    async createOrder(dto: CreateOrderDTO): Promise<Order> {
        // Now uses injected DAO - testable!
        return this.orderDAO.create(dto);
    }
}
 
// ─────────────────────────────────────────────────────────
// STAGE 3: Repository for Core Aggregates (Domain Maturity)
// Trigger: Rich domain logic; aggregate invariants identified
// ─────────────────────────────────────────────────────────
 
// Domain layer (clean, no infrastructure dependencies)
class Order {
    // Rich behavior
    addItem(product: Product, quantity: number): void { /* ... */ }
    submit(): void { /* ... */ }
    applyPayment(payment: Payment): void { /* ... */ }
}
 
interface OrderRepository {
    findById(id: OrderId): Promise<Order | null>;
    save(order: Order): Promise<void>;
}
 
// Infrastructure layer implements repository
class PostgresOrderRepository implements OrderRepository {
    async save(order: Order): Promise<void> {
        // Complex aggregate persistence
        // Might use internal DAOs for table-level operations
    }
}
 
// Application layer orchestrates
class CreateOrderUseCase {
    constructor(private readonly orderRepository: OrderRepository) {}
    
    async execute(command: CreateOrderCommand): Promise<void> {
        const order = Order.create(command);
        await this.orderRepository.save(order);
    }
}

Refactoring Safety

Organizational Considerations

Pattern selection isn't purely technical—organizational factors influence the right choice:

Team and Organization Factors

•Team size and structure — Larger teams benefit from clearer boundaries that DAO/Repository provides. Solo developers may find it overhead.
•Team experience — Junior teams may struggle with additional abstraction layers. Senior teams often demand them for maintainability.
•Database expertise distribution — If only some team members know SQL well, DAOs let them optimize queries while others work on business logic.
•Onboarding considerations — Established patterns with clear conventions speed up new developer ramp-up.
•Multi-team boundaries — When multiple teams access shared data, well-defined DAOs/Repositories establish contracts.
•Code ownership — DAOs provide natural seams for ownership (e.g., data platform team owns DAOs, product teams own services).

Team Context Guidelines
Team Characteristic	Pattern Recommendation	Rationale
Solo / 2-3 developers	Direct ORM or minimal DAO	Speed over structure; less ceremony
Small team (4-7)	DAO for shared entities	Balance pragmatism and structure
Medium team (8-15)	DAO layer + Repository for complex aggregates	Clear boundaries; testability
Large / multi-team	Full pattern library; enforced standards	Coordination; contract definition

Conway's Law

The DAO Decision Framework

Synthesizing the considerations above, here's a practical decision framework:

decision-framework.txt
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
┌─────────────────────────────────────────────────────────┐
│           DAO PATTERN DECISION FRAMEWORK                 │
└─────────────────────────────────────────────────────────┘
 
START: Do you need database abstraction?
        │
        ├─ Multiple storage backends? ─────────────────┐
        │       │                                      │
        │       └─ YES ───────────────────► USE DAO ◄──┘
        │       │
        │       └─ NO ──────────────┐
        │                           ▼
        ├─ Database migration planned? ─────────────────┐
        │       │                                       │
        │       └─ YES ──────────────────► USE DAO ◄────┘
        │       │
        │       └─ NO ──────────────┐
        │                           ▼
        └─ Complex unit testing needs? ─────────────────┐
                │                                       │
                └─ YES ──────────────────► USE DAO ◄────┘
                │
                └─ NO ──────────────┐
                                    ▼
        Do you have a rich domain model?
                │
                ├─ YES + practicing DDD ──► USE REPOSITORY
                │
                ├─ YES + not DDD ─────────► USE DAO (or Repository)
                │
                └─ NO ───────────────┐
                                     ▼
        Is this a simple CRUD application?
                │
                ├─ YES ───────────────────► USE DIRECT ORM
                │
                └─ NO ────────────────────► USE DAO
 
┌─────────────────────────────────────────────────────────┐
│           SIGNALS TO INTRODUCE DAO LATER                 │
└─────────────────────────────────────────────────────────┘
 
• Same queries duplicated in 3+ places
• Test setup requires database for business logic tests
• Query optimization needed without changing services
• Team growing; need clearer architectural boundaries
• Database performance debugging is difficult
• Multiple services access same data differently

Start Conservative

Summary: When to Use DAO

Let's consolidate the decision guidance covered in this module:

Key Takeaways

•Context determines pattern choice — DAO solves specific problems; verify you have those problems before applying the pattern.
•DAO shines with multiple backends — When you access heterogeneous storage, DAO's uniform interface is invaluable.
•Skip DAO for simple CRUD — Small applications with straightforward data access don't need the abstraction.
•Choose Repository for DDD — When practicing Domain-Driven Design with rich aggregates, Repository is the natural pattern.
•Hybrid strategies work — Different parts of your system can use different patterns based on their complexity.
•Evolution is valid — Start simple; introduce patterns when complexity warrants them.
•Consider the team — Pattern selection should account for team size, experience, and organizational structure.

Module Complete:

Module Complete

4 / 4