What Are DTOs — Data Transfer Object… | OneNoughtOne

0/86

System Design (LLD)DTO Design

Data Transfer Object (DTO) Design

LevelIntermediate

Duration50 mins

TopicDTO Design

1 / 4

What Are DTOs

The Hidden Coupling Problem

Picture this scenario: You're a senior engineer at a growing e-commerce platform. Your order management system has been running smoothly for two years, serving hundreds of API consumers—mobile apps, partner integrations, internal dashboards. Then comes a seemingly innocent product requirement: restructure how order statuses work to support a new fulfillment workflow. What should be a simple domain model change becomes a three-month nightmare. Every modification to your Order entity cascades to API responses, breaking mobile clients, invalidating partner integrations, and triggering a wave of support tickets. You've accidentally coupled your internal implementation to your external contracts so tightly that you can't evolve one without breaking the other. This is the coupling crisis that Data Transfer Objects solve.

What You Will Learn

By the end of this page, you will understand what DTOs are, why they exist, their defining characteristics, and their fundamental role in creating maintainable, evolvable software architectures. You'll see how this seemingly simple pattern is actually a critical architectural boundary mechanism.

Defining Data Transfer Objects

A Data Transfer Object (DTO) is an object whose sole purpose is to carry data between processes, layers, or systems. Unlike domain objects that encapsulate both data and behavior, DTOs are intentionally anemic —they contain data and nothing else. No business logic. No validation rules. No computed properties. Just data. The term was first popularized by Martin Fowler in his seminal book Patterns of Enterprise Application Architecture (2002), though the concept predates the name. The pattern emerged from a practical necessity: how do you efficiently transfer data across process boundaries without dragging along all the complexity of your domain model?

order-dto.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
// A DTO is deliberately simple and data-focused
interface OrderDTO {
    // Pure data properties - no methods, no logic
    readonly orderId: string;
    readonly customerName: string;
    readonly orderDate: string;           // ISO 8601 formatted
    readonly totalAmount: number;
    readonly currency: string;
    readonly status: string;
    readonly items: OrderItemDTO[];
    readonly shippingAddress: AddressDTO;
}
 
interface OrderItemDTO {
    readonly productId: string;
    readonly productName: string;
    readonly quantity: number;
    readonly unitPrice: number;
    readonly lineTotal: number;
}
 
interface AddressDTO {
    readonly street: string;
    readonly city: string;
    readonly state: string;
    readonly postalCode: string;
    readonly country: string;
}

The Anemic Design Is Intentional

In domain modeling, anemic objects (data without behavior) are often considered an anti-pattern. But for DTOs, this anemic nature is a feature, not a bug. DTOs are not meant to model business concepts—they're meant to model the shape of data as it crosses boundaries. Their simplicity is their strength.

The key insight: DTOs are about communication contract, not domain truth . They define how data looks when it travels, independent of how it's structured internally.

The Origin and Purpose of DTOs

DTOs didn't emerge from theoretical computer science—they evolved from practical pain. In the early days of distributed computing (particularly Java's EJB era), developers discovered that passing domain objects across network boundaries was problematic for multiple reasons: Serialization complexity — Domain objects often have circular references, lazy-loaded collections, and framework-specific proxies that don't serialize cleanly Performance overhead — Domain objects may carry far more data than the receiver needs Tight coupling — Exposing domain objects binds external consumers to internal implementation details Security risks — Domain objects may contain sensitive data that shouldn't cross boundaries

The Problems DTOs Solve
Problem	Without DTOs	With DTOs
API Evolution	Changing domain model breaks all clients	DTO remains stable; mapping absorbs changes
Data Exposure	Clients see internal implementation details	Only intentionally exposed data is visible
Serialization	Complex object graphs cause issues	Flat, serialization-friendly structures
Payload Size	Entire object graph transferred	Only needed data included
Security	Sensitive fields accidentally exposed	Explicit control over exposed fields
Versioning	Single structure for all versions	Version-specific DTOs coexist

The core purpose of DTOs is architectural decoupling. They create a clear boundary between what you store/process internally and what you expose externally. This separation enables: Independent evolution — Your domain model can change without forcing API version bumps Consumer-optimized structures — Different consumers can receive data shaped for their needs Clean serialization — Simple structures that serialize predictably to JSON, XML, or Protocol Buffers Explicit contracts — The DTO is the contract; there's no hidden behavior or side effects

DTOs in Modern Development

While DTOs originated in the EJB/CORBA era for remote procedure calls, their relevance has grown with REST APIs, GraphQL, microservices, and mobile applications. The need to decouple internal structure from external contract is more important than ever when you have diverse clients with different data needs and release cycles.

Characteristics of Well-Designed DTOs

Not all objects that carry data are well-designed DTOs. A properly crafted DTO exhibits specific characteristics that make it effective as a boundary-crossing mechanism:

Essential DTO Characteristics

•No Business Logic — DTOs contain only data. All validation, computation, and business rules live elsewhere. A DTO is a passive data container.
•Serialization-Friendly — Every field has a type that serializes cleanly. No framework proxies, no lazy-loading markers, no circular references.
•Flat or Shallow Nesting — DTOs prefer flat structures. When nesting is necessary, it's explicit and bounded. Deeply nested DTOs signal design problems.
•Primitive Obsession Is Acceptable — Unlike domain models where we'd wrap concepts in value objects, DTOs often use primitives (strings, numbers) for simplicity in serialization.
•Immutability Preferred — Once created, a DTO shouldn't change. This prevents accidental mutation during transfer and makes DTOs thread-safe.
•Self-Describing Field Names — Since DTOs are contracts, field names should be clear without needing domain knowledge: customerEmailAddress not email.
•Explicit Nullability — DTOs make it clear which fields can be null/undefined. This prevents NPE surprises for consumers.

well-designed-dto.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
// Well-designed DTO showcasing key characteristics
interface CustomerOrderSummaryDTO {
    // Clear, self-describing names
    readonly orderId: string;
    readonly customerFullName: string;
    readonly customerEmailAddress: string;
    
    // Serialization-friendly date format (not Date object)
    readonly orderPlacedAt: string;    // ISO 8601
    
    // Explicit nullability
    readonly shippedAt: string | null;
    readonly deliveredAt: string | null;
    
    // Primitive types for simple serialization
    readonly orderTotalCents: number;  // Avoid float precision issues
    readonly currencyCode: string;     // "USD", "EUR", etc.
    
    // Finite set of values as string enum
    readonly orderStatus: 'pending' | 'processing' | 'shipped' | 'delivered';
    
    // Shallow nesting with bounded depth
    readonly items: OrderItemSummaryDTO[];  // Simple nested array
}
 
// The nested DTO is also flat and simple
interface OrderItemSummaryDTO {
    readonly productSku: string;
    readonly productDisplayName: string;
    readonly quantity: number;
    readonly unitPriceCents: number;
    readonly totalPriceCents: number;
}

Watch for DTO Smell: Behavior Creep

If you find yourself adding methods to a DTO—even 'convenience' methods like getFormattedDate() or calculateTotal() —stop. That's behavior creeping in. Either the consuming code should handle formatting, or you need a dedicated presentation layer. A DTO with methods is no longer a DTO.

DTOs as Boundary Protection

One of the most powerful roles DTOs play is as architectural boundary guards . In a well-designed system, DTOs sit at every point where data crosses a significant boundary: Between your API and external clients Between microservices Between application layers (in some architectures) Between your system and third-party integrations

architectural-boundaries.txt

┌─────────────────────────────────────────────────────────────────┐
│                        EXTERNAL WORLD                           │
│     Mobile Apps    │    Partner APIs    │    Web Clients        │
└────────────────────┴───────────────────┴───────────────────────┘
                              │
                              │ JSON (DTOs)
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                      API BOUNDARY (Controller)                   │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │           Request DTOs        Response DTOs              │   │
│  │    CreateOrderRequest ─────► OrderDetailsResponse        │   │
│  │    UpdateOrderRequest ─────► OrderSummaryResponse        │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
                              │
                              │ Domain Objects
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                     APPLICATION CORE (Domain)                    │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │        Order Entity         OrderService                 │   │
│  │        OrderItem Entity     PaymentService               │   │
│  │        Customer Entity      InventoryService             │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
                              │
                              │ Persistence DTOs / Entities
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                     INFRASTRUCTURE (Persistence)                 │
│       Database Tables    │    External Service Clients          │
└─────────────────────────────────────────────────────────────────┘

This boundary protection yields profound benefits: 1. Domain Isolation Your domain model is free to evolve based on business needs without worrying about serialization concerns, API compatibility, or external consumer requirements. The DTO layer absorbs the translation. 2. Contract Stability External consumers depend on DTOs, not domain objects. Even if your internal Order entity gains ten new fields or splits into multiple entities, the OrderSummaryDTO can remain unchanged. 3. Security by Design Fields must be explicitly included in DTOs to be exposed. This is far safer than trying to exclude fields from domain objects using serialization annotations. Whitelisting is safer than blacklisting.

security-by-design.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
// Domain entity - has EVERYTHING
interface UserEntity {
    id: string;
    email: string;
    passwordHash: string;           // NEVER expose
    passwordSalt: string;           // NEVER expose
    twoFactorSecret: string | null; // NEVER expose
    failedLoginAttempts: number;    // Internal tracking
    isLockedOut: boolean;
    lastPasswordChangeAt: Date;
    createdAt: Date;
    updatedAt: Date;
    internalNotes: string;          // Admin-only
    creditScore: number;            // Sensitive PII
    socialSecurityNumber: string;   // Extremely sensitive
}
 
// Public-facing DTO - ONLY what external clients may see
interface UserProfileDTO {
    readonly userId: string;
    readonly emailAddress: string;
    readonly accountCreatedAt: string;
    readonly isVerified: boolean;
}
 
// Admin-facing DTO - more data, still no secrets
interface AdminUserViewDTO {
    readonly userId: string;
    readonly emailAddress: string;
    readonly accountCreatedAt: string;
    readonly lastLoginAt: string | null;
    readonly isLockedOut: boolean;
    readonly failedLoginAttempts: number;
    // Note: still no password hashes, SSN, etc.
}
 
// The mapper explicitly selects what to expose
function toUserProfileDTO(user: UserEntity): UserProfileDTO {
    return {
        userId: user.id,
        emailAddress: user.email,
        accountCreatedAt: user.createdAt.toISOString(),
        isVerified: user.emailVerifiedAt !== null,
    };
}

The Explicit Selection Principle

A well-designed DTO mapper explicitly copies only the fields that should be exposed. This is vastly safer than serializing domain objects with @JsonIgnore annotations. With explicit mapping, forgetting to add a field to the DTO means it's not exposed. With annotation-based exclusion, forgetting an annotation means accidental exposure.

Request DTOs vs Response DTOs

DTOs typically come in two flavors based on their direction of travel: Request DTOs (Inbound) — Carry data from external consumers into your system. They represent what consumers are allowed to send . Response DTOs (Outbound) — Carry data from your system to external consumers. They represent what consumers will receive . These serve different purposes and should almost always be distinct types, even when they seem similar.

Request DTOs (Inbound)

•Define what clients can send
•Contain writable, mutable fields
•May have fields that don't map 1:1 to domain
•Often validated at controller level
•No computed or derived fields
•May include idempotency keys or client references
•Example: CreateOrderRequest

Response DTOs (Outbound)

•Define what clients will receive
•Should be immutable once created
•Include computed/derived fields for convenience
•May include hypermedia links (HATEOAS)
•Often include metadata (timestamps, version)
•May have different detail levels (summary vs full)
•Example: OrderDetailsResponse

request-response-dtos.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
// === REQUEST DTOs ===
// What clients send when creating an order
interface CreateOrderRequest {
    customerId: string;
    shippingAddressId: string;
    items: CreateOrderItemRequest[];
    paymentMethodId: string;
    idempotencyKey: string;  // Client-provided for safe retries
    couponCode?: string;     // Optional field
}
 
interface CreateOrderItemRequest {
    productId: string;
    quantity: number;
    // Note: no prices - server determines pricing
}
 
// === RESPONSE DTOs ===
// What clients receive after order creation
interface CreateOrderResponse {
    readonly orderId: string;
    readonly orderNumber: string;          // Human-readable reference
    readonly status: OrderStatus;
    readonly createdAt: string;
    readonly estimatedDeliveryDate: string;
    
    // Computed/derived values the client shouldn't calculate
    readonly subtotalCents: number;
    readonly discountCents: number;
    readonly taxCents: number;
    readonly totalCents: number;
    
    // Nested response DTOs
    readonly items: OrderItemResponse[];
    readonly shippingAddress: AddressResponse;
    
    // Hypermedia for discoverability
    readonly links: {
        readonly self: string;
        readonly cancel: string | null;   // null if not cancellable
        readonly tracking: string | null;  // null if not shipped
    };
}
 
interface OrderItemResponse {
    readonly lineItemId: string;
    readonly productId: string;
    readonly productName: string;          // Resolved at creation time
    readonly productImageUrl: string;      // For display
    readonly quantity: number;
    readonly unitPriceCents: number;
    readonly lineTotalCents: number;       // Computed: quantity * unitPrice
}

Why Separate Types?

It's tempting to create a single OrderDTO for both input and output. Resist this temptation. Input and output have different concerns: inputs need validation constraints, outputs need computed fields. Conflating them leads to confusion—which fields are required? Which are read-only? Separate DTOs make the contract crystal clear.

Common DTO Patterns

Over years of API design, several patterns have emerged for organizing and structuring DTOs effectively:

Pattern 1: Summary vs Detail DTOs For any entity, you often need multiple views—a compact summary for listings and a detailed view for individual fetch. Rather than making all fields optional, create distinct DTO types:

summary-detail-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
// Compact summary for list views
interface OrderSummaryDTO {
    readonly orderId: string;
    readonly orderNumber: string;
    readonly status: string;
    readonly createdAt: string;
    readonly totalCents: number;
    readonly itemCount: number;
}
 
// Full detail for individual order view
interface OrderDetailDTO {
    // All summary fields...
    readonly orderId: string;
    readonly orderNumber: string;
    readonly status: string;
    readonly createdAt: string;
    readonly totalCents: number;
    
    // Plus detailed information...
    readonly customer: CustomerSummaryDTO;
    readonly items: OrderItemDetailDTO[];
    readonly shippingAddress: AddressDTO;
    readonly billingAddress: AddressDTO;
    readonly paymentMethod: PaymentMethodSummaryDTO;
    readonly statusHistory: OrderStatusChangeDTO[];
    readonly notes: OrderNoteDTO[];
}
 
// API usage:
// GET /orders           → OrderSummaryDTO[]   (list)
// GET /orders/{id}      → OrderDetailDTO       (single)

Pattern 2: Envelope/Wrapper DTOs Wrap response data in a consistent envelope that includes metadata:

envelope-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
// Generic envelope for all responses
interface ApiResponse<T> {
    readonly data: T;
    readonly meta: ResponseMeta;
}
 
interface ResponseMeta {
    readonly requestId: string;
    readonly timestamp: string;
    readonly version: string;     // API version
}
 
// Paginated envelope extends the base envelope
interface PaginatedResponse<T> {
    readonly data: T[];
    readonly meta: ResponseMeta;
    readonly pagination: PaginationInfo;
}
 
interface PaginationInfo {
    readonly currentPage: number;
    readonly pageSize: number;
    readonly totalItems: number;
    readonly totalPages: number;
    readonly hasNextPage: boolean;
    readonly hasPreviousPage: boolean;
}
 
// Usage example:
// GET /orders → PaginatedResponse<OrderSummaryDTO>
// GET /orders/123 → ApiResponse<OrderDetailDTO>

Pattern 3: Composite/Aggregate DTOs Sometimes a single API call should return a cohesive bundle of related data:

composite-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
// Dashboard aggregates multiple concerns into one response
interface OrderDashboardDTO {
    readonly summary: {
        readonly totalOrders: number;
        readonly pendingOrders: number;
        readonly completedOrders: number;
        readonly totalRevenueCents: number;
    };
    readonly recentOrders: OrderSummaryDTO[];
    readonly topProducts: ProductPerformanceDTO[];
    readonly alerts: DashboardAlertDTO[];
}
 
// Checkout bundles everything needed for one screen
interface CheckoutStateDTO {
    readonly cart: CartDTO;
    readonly customer: CustomerDTO;
    readonly availableShippingMethods: ShippingMethodDTO[];
    readonly availablePaymentMethods: PaymentMethodDTO[];
    readonly appliedCoupons: AppliedCouponDTO[];
    readonly pricing: PricingBreakdownDTO;
    readonly estimatedDelivery: DeliveryEstimateDTO;
}

Match DTOs to Use Cases

Rather than creating generic DTOs and hoping they fit all situations, design DTOs for specific use cases. A CheckoutStateDTO that matches exactly what the checkout screen needs is more useful than three separate API calls that the client must correlate.

When NOT to Use DTOs

While DTOs are powerful, they're not always necessary. Introducing DTOs has a cost—additional classes, mapping code, and cognitive overhead. Here are situations where DTOs may be overkill:

Consider Skipping DTOs When...

•Simple CRUD operations — If your domain objects map 1:1 to your API and are unlikely to diverge, direct serialization may be acceptable (though still risky).
•Internal tools — Admin dashboards or internal-only APIs where breaking changes are easily communicated and deployed together.
•Prototyping — Early-stage development where contracts haven't stabilized. But be prepared to add DTOs before production.
•Truly simple microservices — Services with minimal domain logic that essentially just pass data through.
•Event payload within bounded context — Internal events consumed only by services you control may use simpler structures.

The Regret Threshold

Most teams that skip DTOs eventually regret it. The point of regret is usually when: (1) they need to make a breaking change to the domain model, (2) they accidentally expose sensitive data, or (3) different consumers need different views of the same data. Adding DTOs later is painful—it's easier to start with them.

The cost-benefit analysis: DTOs add approximately 20-30% more code for API boundaries. But they can save you from 10x more refactoring work later. For any API that: Will be consumed by external parties Will need to evolve over time Contains any sensitive data Has domain models with complex object graphs ...the investment in DTOs pays for itself quickly.

System Design (LLD)DTO Design

Data Transfer Object (DTO) Design

LevelIntermediate

Duration50 mins

TopicDTO Design

1 / 4

What Are DTOs

The Hidden Coupling Problem

Picture this scenario: You're a senior engineer at a growing e-commerce platform. Your order management system has been running smoothly for two years, serving hundreds of API consumers—mobile apps, partner integrations, internal dashboards. Then comes a seemingly innocent product requirement: restructure how order statuses work to support a new fulfillment workflow. What should be a simple domain model change becomes a three-month nightmare. Every modification to your Order entity cascades to API responses, breaking mobile clients, invalidating partner integrations, and triggering a wave of support tickets. You've accidentally coupled your internal implementation to your external contracts so tightly that you can't evolve one without breaking the other. This is the coupling crisis that Data Transfer Objects solve.

What You Will Learn

By the end of this page, you will understand what DTOs are, why they exist, their defining characteristics, and their fundamental role in creating maintainable, evolvable software architectures. You'll see how this seemingly simple pattern is actually a critical architectural boundary mechanism.

Defining Data Transfer Objects

A Data Transfer Object (DTO) is an object whose sole purpose is to carry data between processes, layers, or systems. Unlike domain objects that encapsulate both data and behavior, DTOs are intentionally anemic —they contain data and nothing else. No business logic. No validation rules. No computed properties. Just data. The term was first popularized by Martin Fowler in his seminal book Patterns of Enterprise Application Architecture (2002), though the concept predates the name. The pattern emerged from a practical necessity: how do you efficiently transfer data across process boundaries without dragging along all the complexity of your domain model?

order-dto.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
// A DTO is deliberately simple and data-focused
interface OrderDTO {
    // Pure data properties - no methods, no logic
    readonly orderId: string;
    readonly customerName: string;
    readonly orderDate: string;           // ISO 8601 formatted
    readonly totalAmount: number;
    readonly currency: string;
    readonly status: string;
    readonly items: OrderItemDTO[];
    readonly shippingAddress: AddressDTO;
}
 
interface OrderItemDTO {
    readonly productId: string;
    readonly productName: string;
    readonly quantity: number;
    readonly unitPrice: number;
    readonly lineTotal: number;
}
 
interface AddressDTO {
    readonly street: string;
    readonly city: string;
    readonly state: string;
    readonly postalCode: string;
    readonly country: string;
}

The Anemic Design Is Intentional

In domain modeling, anemic objects (data without behavior) are often considered an anti-pattern. But for DTOs, this anemic nature is a feature, not a bug. DTOs are not meant to model business concepts—they're meant to model the shape of data as it crosses boundaries. Their simplicity is their strength.

The key insight: DTOs are about communication contract, not domain truth . They define how data looks when it travels, independent of how it's structured internally.

The Origin and Purpose of DTOs

DTOs didn't emerge from theoretical computer science—they evolved from practical pain. In the early days of distributed computing (particularly Java's EJB era), developers discovered that passing domain objects across network boundaries was problematic for multiple reasons: Serialization complexity — Domain objects often have circular references, lazy-loaded collections, and framework-specific proxies that don't serialize cleanly Performance overhead — Domain objects may carry far more data than the receiver needs Tight coupling — Exposing domain objects binds external consumers to internal implementation details Security risks — Domain objects may contain sensitive data that shouldn't cross boundaries

The Problems DTOs Solve
Problem	Without DTOs	With DTOs
API Evolution	Changing domain model breaks all clients	DTO remains stable; mapping absorbs changes
Data Exposure	Clients see internal implementation details	Only intentionally exposed data is visible
Serialization	Complex object graphs cause issues	Flat, serialization-friendly structures
Payload Size	Entire object graph transferred	Only needed data included
Security	Sensitive fields accidentally exposed	Explicit control over exposed fields
Versioning	Single structure for all versions	Version-specific DTOs coexist

The core purpose of DTOs is architectural decoupling. They create a clear boundary between what you store/process internally and what you expose externally. This separation enables: Independent evolution — Your domain model can change without forcing API version bumps Consumer-optimized structures — Different consumers can receive data shaped for their needs Clean serialization — Simple structures that serialize predictably to JSON, XML, or Protocol Buffers Explicit contracts — The DTO is the contract; there's no hidden behavior or side effects

DTOs in Modern Development

While DTOs originated in the EJB/CORBA era for remote procedure calls, their relevance has grown with REST APIs, GraphQL, microservices, and mobile applications. The need to decouple internal structure from external contract is more important than ever when you have diverse clients with different data needs and release cycles.

Characteristics of Well-Designed DTOs

Not all objects that carry data are well-designed DTOs. A properly crafted DTO exhibits specific characteristics that make it effective as a boundary-crossing mechanism:

Essential DTO Characteristics

•No Business Logic — DTOs contain only data. All validation, computation, and business rules live elsewhere. A DTO is a passive data container.
•Serialization-Friendly — Every field has a type that serializes cleanly. No framework proxies, no lazy-loading markers, no circular references.
•Flat or Shallow Nesting — DTOs prefer flat structures. When nesting is necessary, it's explicit and bounded. Deeply nested DTOs signal design problems.
•Primitive Obsession Is Acceptable — Unlike domain models where we'd wrap concepts in value objects, DTOs often use primitives (strings, numbers) for simplicity in serialization.
•Immutability Preferred — Once created, a DTO shouldn't change. This prevents accidental mutation during transfer and makes DTOs thread-safe.
•Self-Describing Field Names — Since DTOs are contracts, field names should be clear without needing domain knowledge: customerEmailAddress not email.
•Explicit Nullability — DTOs make it clear which fields can be null/undefined. This prevents NPE surprises for consumers.

well-designed-dto.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
// Well-designed DTO showcasing key characteristics
interface CustomerOrderSummaryDTO {
    // Clear, self-describing names
    readonly orderId: string;
    readonly customerFullName: string;
    readonly customerEmailAddress: string;
    
    // Serialization-friendly date format (not Date object)
    readonly orderPlacedAt: string;    // ISO 8601
    
    // Explicit nullability
    readonly shippedAt: string | null;
    readonly deliveredAt: string | null;
    
    // Primitive types for simple serialization
    readonly orderTotalCents: number;  // Avoid float precision issues
    readonly currencyCode: string;     // "USD", "EUR", etc.
    
    // Finite set of values as string enum
    readonly orderStatus: 'pending' | 'processing' | 'shipped' | 'delivered';
    
    // Shallow nesting with bounded depth
    readonly items: OrderItemSummaryDTO[];  // Simple nested array
}
 
// The nested DTO is also flat and simple
interface OrderItemSummaryDTO {
    readonly productSku: string;
    readonly productDisplayName: string;
    readonly quantity: number;
    readonly unitPriceCents: number;
    readonly totalPriceCents: number;
}

Watch for DTO Smell: Behavior Creep

If you find yourself adding methods to a DTO—even 'convenience' methods like getFormattedDate() or calculateTotal() —stop. That's behavior creeping in. Either the consuming code should handle formatting, or you need a dedicated presentation layer. A DTO with methods is no longer a DTO.

DTOs as Boundary Protection

One of the most powerful roles DTOs play is as architectural boundary guards . In a well-designed system, DTOs sit at every point where data crosses a significant boundary: Between your API and external clients Between microservices Between application layers (in some architectures) Between your system and third-party integrations

architectural-boundaries.txt

┌─────────────────────────────────────────────────────────────────┐
│                        EXTERNAL WORLD                           │
│     Mobile Apps    │    Partner APIs    │    Web Clients        │
└────────────────────┴───────────────────┴───────────────────────┘
                              │
                              │ JSON (DTOs)
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                      API BOUNDARY (Controller)                   │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │           Request DTOs        Response DTOs              │   │
│  │    CreateOrderRequest ─────► OrderDetailsResponse        │   │
│  │    UpdateOrderRequest ─────► OrderSummaryResponse        │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
                              │
                              │ Domain Objects
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                     APPLICATION CORE (Domain)                    │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │        Order Entity         OrderService                 │   │
│  │        OrderItem Entity     PaymentService               │   │
│  │        Customer Entity      InventoryService             │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
                              │
                              │ Persistence DTOs / Entities
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                     INFRASTRUCTURE (Persistence)                 │
│       Database Tables    │    External Service Clients          │
└─────────────────────────────────────────────────────────────────┘

This boundary protection yields profound benefits: 1. Domain Isolation Your domain model is free to evolve based on business needs without worrying about serialization concerns, API compatibility, or external consumer requirements. The DTO layer absorbs the translation. 2. Contract Stability External consumers depend on DTOs, not domain objects. Even if your internal Order entity gains ten new fields or splits into multiple entities, the OrderSummaryDTO can remain unchanged. 3. Security by Design Fields must be explicitly included in DTOs to be exposed. This is far safer than trying to exclude fields from domain objects using serialization annotations. Whitelisting is safer than blacklisting.

security-by-design.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
// Domain entity - has EVERYTHING
interface UserEntity {
    id: string;
    email: string;
    passwordHash: string;           // NEVER expose
    passwordSalt: string;           // NEVER expose
    twoFactorSecret: string | null; // NEVER expose
    failedLoginAttempts: number;    // Internal tracking
    isLockedOut: boolean;
    lastPasswordChangeAt: Date;
    createdAt: Date;
    updatedAt: Date;
    internalNotes: string;          // Admin-only
    creditScore: number;            // Sensitive PII
    socialSecurityNumber: string;   // Extremely sensitive
}
 
// Public-facing DTO - ONLY what external clients may see
interface UserProfileDTO {
    readonly userId: string;
    readonly emailAddress: string;
    readonly accountCreatedAt: string;
    readonly isVerified: boolean;
}
 
// Admin-facing DTO - more data, still no secrets
interface AdminUserViewDTO {
    readonly userId: string;
    readonly emailAddress: string;
    readonly accountCreatedAt: string;
    readonly lastLoginAt: string | null;
    readonly isLockedOut: boolean;
    readonly failedLoginAttempts: number;
    // Note: still no password hashes, SSN, etc.
}
 
// The mapper explicitly selects what to expose
function toUserProfileDTO(user: UserEntity): UserProfileDTO {
    return {
        userId: user.id,
        emailAddress: user.email,
        accountCreatedAt: user.createdAt.toISOString(),
        isVerified: user.emailVerifiedAt !== null,
    };
}

The Explicit Selection Principle

A well-designed DTO mapper explicitly copies only the fields that should be exposed. This is vastly safer than serializing domain objects with @JsonIgnore annotations. With explicit mapping, forgetting to add a field to the DTO means it's not exposed. With annotation-based exclusion, forgetting an annotation means accidental exposure.

Request DTOs vs Response DTOs

DTOs typically come in two flavors based on their direction of travel: Request DTOs (Inbound) — Carry data from external consumers into your system. They represent what consumers are allowed to send . Response DTOs (Outbound) — Carry data from your system to external consumers. They represent what consumers will receive . These serve different purposes and should almost always be distinct types, even when they seem similar.

Request DTOs (Inbound)

•Define what clients can send
•Contain writable, mutable fields
•May have fields that don't map 1:1 to domain
•Often validated at controller level
•No computed or derived fields
•May include idempotency keys or client references
•Example: CreateOrderRequest

Response DTOs (Outbound)

•Define what clients will receive
•Should be immutable once created
•Include computed/derived fields for convenience
•May include hypermedia links (HATEOAS)
•Often include metadata (timestamps, version)
•May have different detail levels (summary vs full)
•Example: OrderDetailsResponse

request-response-dtos.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
// === REQUEST DTOs ===
// What clients send when creating an order
interface CreateOrderRequest {
    customerId: string;
    shippingAddressId: string;
    items: CreateOrderItemRequest[];
    paymentMethodId: string;
    idempotencyKey: string;  // Client-provided for safe retries
    couponCode?: string;     // Optional field
}
 
interface CreateOrderItemRequest {
    productId: string;
    quantity: number;
    // Note: no prices - server determines pricing
}
 
// === RESPONSE DTOs ===
// What clients receive after order creation
interface CreateOrderResponse {
    readonly orderId: string;
    readonly orderNumber: string;          // Human-readable reference
    readonly status: OrderStatus;
    readonly createdAt: string;
    readonly estimatedDeliveryDate: string;
    
    // Computed/derived values the client shouldn't calculate
    readonly subtotalCents: number;
    readonly discountCents: number;
    readonly taxCents: number;
    readonly totalCents: number;
    
    // Nested response DTOs
    readonly items: OrderItemResponse[];
    readonly shippingAddress: AddressResponse;
    
    // Hypermedia for discoverability
    readonly links: {
        readonly self: string;
        readonly cancel: string | null;   // null if not cancellable
        readonly tracking: string | null;  // null if not shipped
    };
}
 
interface OrderItemResponse {
    readonly lineItemId: string;
    readonly productId: string;
    readonly productName: string;          // Resolved at creation time
    readonly productImageUrl: string;      // For display
    readonly quantity: number;
    readonly unitPriceCents: number;
    readonly lineTotalCents: number;       // Computed: quantity * unitPrice
}

Why Separate Types?

It's tempting to create a single OrderDTO for both input and output. Resist this temptation. Input and output have different concerns: inputs need validation constraints, outputs need computed fields. Conflating them leads to confusion—which fields are required? Which are read-only? Separate DTOs make the contract crystal clear.

Common DTO Patterns

Over years of API design, several patterns have emerged for organizing and structuring DTOs effectively:

Pattern 1: Summary vs Detail DTOs For any entity, you often need multiple views—a compact summary for listings and a detailed view for individual fetch. Rather than making all fields optional, create distinct DTO types:

summary-detail-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
// Compact summary for list views
interface OrderSummaryDTO {
    readonly orderId: string;
    readonly orderNumber: string;
    readonly status: string;
    readonly createdAt: string;
    readonly totalCents: number;
    readonly itemCount: number;
}
 
// Full detail for individual order view
interface OrderDetailDTO {
    // All summary fields...
    readonly orderId: string;
    readonly orderNumber: string;
    readonly status: string;
    readonly createdAt: string;
    readonly totalCents: number;
    
    // Plus detailed information...
    readonly customer: CustomerSummaryDTO;
    readonly items: OrderItemDetailDTO[];
    readonly shippingAddress: AddressDTO;
    readonly billingAddress: AddressDTO;
    readonly paymentMethod: PaymentMethodSummaryDTO;
    readonly statusHistory: OrderStatusChangeDTO[];
    readonly notes: OrderNoteDTO[];
}
 
// API usage:
// GET /orders           → OrderSummaryDTO[]   (list)
// GET /orders/{id}      → OrderDetailDTO       (single)

Pattern 2: Envelope/Wrapper DTOs Wrap response data in a consistent envelope that includes metadata:

envelope-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
// Generic envelope for all responses
interface ApiResponse<T> {
    readonly data: T;
    readonly meta: ResponseMeta;
}
 
interface ResponseMeta {
    readonly requestId: string;
    readonly timestamp: string;
    readonly version: string;     // API version
}
 
// Paginated envelope extends the base envelope
interface PaginatedResponse<T> {
    readonly data: T[];
    readonly meta: ResponseMeta;
    readonly pagination: PaginationInfo;
}
 
interface PaginationInfo {
    readonly currentPage: number;
    readonly pageSize: number;
    readonly totalItems: number;
    readonly totalPages: number;
    readonly hasNextPage: boolean;
    readonly hasPreviousPage: boolean;
}
 
// Usage example:
// GET /orders → PaginatedResponse<OrderSummaryDTO>
// GET /orders/123 → ApiResponse<OrderDetailDTO>

Pattern 3: Composite/Aggregate DTOs Sometimes a single API call should return a cohesive bundle of related data:

composite-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
// Dashboard aggregates multiple concerns into one response
interface OrderDashboardDTO {
    readonly summary: {
        readonly totalOrders: number;
        readonly pendingOrders: number;
        readonly completedOrders: number;
        readonly totalRevenueCents: number;
    };
    readonly recentOrders: OrderSummaryDTO[];
    readonly topProducts: ProductPerformanceDTO[];
    readonly alerts: DashboardAlertDTO[];
}
 
// Checkout bundles everything needed for one screen
interface CheckoutStateDTO {
    readonly cart: CartDTO;
    readonly customer: CustomerDTO;
    readonly availableShippingMethods: ShippingMethodDTO[];
    readonly availablePaymentMethods: PaymentMethodDTO[];
    readonly appliedCoupons: AppliedCouponDTO[];
    readonly pricing: PricingBreakdownDTO;
    readonly estimatedDelivery: DeliveryEstimateDTO;
}

Match DTOs to Use Cases

Rather than creating generic DTOs and hoping they fit all situations, design DTOs for specific use cases. A CheckoutStateDTO that matches exactly what the checkout screen needs is more useful than three separate API calls that the client must correlate.

When NOT to Use DTOs

While DTOs are powerful, they're not always necessary. Introducing DTOs has a cost—additional classes, mapping code, and cognitive overhead. Here are situations where DTOs may be overkill:

Consider Skipping DTOs When...

•Simple CRUD operations — If your domain objects map 1:1 to your API and are unlikely to diverge, direct serialization may be acceptable (though still risky).
•Internal tools — Admin dashboards or internal-only APIs where breaking changes are easily communicated and deployed together.
•Prototyping — Early-stage development where contracts haven't stabilized. But be prepared to add DTOs before production.
•Truly simple microservices — Services with minimal domain logic that essentially just pass data through.
•Event payload within bounded context — Internal events consumed only by services you control may use simpler structures.

The Regret Threshold

Most teams that skip DTOs eventually regret it. The point of regret is usually when: (1) they need to make a breaking change to the domain model, (2) they accidentally expose sensitive data, or (3) different consumers need different views of the same data. Adding DTOs later is painful—it's easier to start with them.

The cost-benefit analysis: DTOs add approximately 20-30% more code for API boundaries. But they can save you from 10x more refactoring work later. For any API that: Will be consumed by external parties Will need to evolve over time Contains any sensitive data Has domain models with complex object graphs ...the investment in DTOs pays for itself quickly.

What Are DTOs

The Hidden Coupling Problem

Defining Data Transfer Objects

The Origin and Purpose of DTOs

Characteristics of Well-Designed DTOs

DTOs as Boundary Protection

Request DTOs vs Response DTOs

Common DTO Patterns

When NOT to Use DTOs

There’s more to understand.

What Are DTOs

The Hidden Coupling Problem

Defining Data Transfer Objects

The Origin and Purpose of DTOs

Characteristics of Well-Designed DTOs

DTOs as Boundary Protection

Request DTOs vs Response DTOs

Common DTO Patterns

When NOT to Use DTOs

There’s more to understand.