DTO vs. Value Object

DTOs and value objects are often confused because both can look small, immutable, and data-oriented. In Java, they serve different roles.

The Core Difference

A DTO exists for transfer across a boundary. A value object exists to model a concept inside the domain.

That means the main question is not “do they both have fields?” The main question is “what job does this type do?”

A Value Object Owns Meaning

 1public record Money(BigDecimal amount, Currency currency) {
 2    public Money {
 3        if (amount.signum() < 0) {
 4            throw new IllegalArgumentException("Amount must be non-negative");
 5        }
 6    }
 7
 8    public Money add(Money other) {
 9        if (!currency.equals(other.currency)) {
10            throw new IllegalArgumentException("Currency mismatch");
11        }
12        return new Money(amount.add(other.amount), currency);
13    }
14}

Money is not just carrying fields. It owns invariants and meaningful behavior.

A DTO Owns A Boundary Shape

1public record InvoiceResponseDto(
2    String id,
3    String currency,
4    String amount,
5    String status
6) {}

This type exists because a response contract needs those fields in that format. It does not need domain arithmetic or currency-rule enforcement.

Why The Difference Matters

If a value object is treated like a DTO, the system may lose important invariants. If a DTO is treated like a value object, boundary code may inherit domain assumptions or internal structure it should not expose.

The two patterns can work together:

• domain model uses value objects
• mappers flatten or translate those value objects into DTO fields for transport

That is often the healthy relationship.

Java-Specific Guidance

Records can implement either pattern. The syntax does not decide the role.

A record with validation and meaningful operations can be a value object. A record with no behavior and boundary-specific fields can be a DTO. The key is the role in the system, not the language feature used to write it.

Design Review Questions

When reviewing Java DTOs and value objects, ask:

• Is this type shaped by the domain or by the boundary?
• Does it own invariants or simply transport already-derived data?
• Would exposing this type publicly leak internal model meaning?
• Is equality central to the concept or merely incidental to transport?

DTO and value object can both be excellent small types. They become confusing only when the codebase stops naming their roles clearly.