VO vs. DTO: Definitions and the History of Conflating the Terms

A Value Object is an object that has no identity and whose equality is determined by the values it holds.

Identity is the property that distinguishes one object from another regardless of its attribute values. A member is still the same member after their name or address changes, and two members with the same name and address are still different people. Such objects are distinguished by an identifier like a member number, and DDD calls them ENTITIES.

Equality is the criterion for deciding whether two objects count as the same. A Value Object bases this criterion on the values it holds rather than on an identifier. Concepts like money, color, and date are typical examples. For instance, Instant in Java, which represents a point on the timeline, compares equal with equals() when two instances refer to the same instant, even if they were created separately by different means.

This definition can be confirmed in the three sources below.

Eric Evans takes the same view. In the Value Objects entry of the Domain-Driven Design Reference (2015), which Evans published as a summary of the pattern definitions in Domain-Driven Design, the problem statement presupposes that many objects have no conceptual identity, and it says to classify a model element as a value object when you care only about its attributes and logic.

In Java code, a class that expresses a value concept becomes a Value Object when it implements equals() and hashCode() on the attributes that serve as the criterion for equality. The contracts of these two methods that must be honored are laid out in Item 10 and Item 11 of Joshua Bloch’s Effective Java, 3rd ed.

With records, which became a standard feature in Java 16, you no longer have to write these two methods yourself. JEP 395, which introduced records, states that a record’s equals() and hashCode() are generated automatically based on the values of all its components. Two record instances are equal when they have the same type and all of their component values are equal.

Two instances of this class are equal when the values they hold are the same.

However, because a record uses the equals() of each component type as is, the automatically generated equality may differ from the equality the domain wants. For example, BigDecimal’s `equals() compares the scale as well, so Money instances created from new BigDecimal("10000") and new BigDecimal("10000.0") end up as different values. In such cases, normalize the values in the constructor or define equals() yourself.

The concept of an identity-free value object is also being introduced into the Java language and the JVM. It shares with the Value Object of DDD and Fowler the trait of being distinguished by value, without identity. Project Valhalla’s JEP 401: Value Objects (Preview) proposes value objects that are immutable, have no object identity, and are distinguished only by their field values. As of August 2026, this JEP has been integrated as a preview feature into JDK 28, scheduled for release in March 2027. JEP 169: Larval State for Value Objects is a separate Draft proposal that deals with a temporary mutable state for these immutable value objects. That said, identity in DDD is a question of whether something needs to be conceptually distinguished in the domain, while the identity that Valhalla removes is a runtime property by which the JVM tells objects apart, so the two value objects are not the same concept. Even so, neither side uses value object to mean an object with nothing but getters and setters.

Meanwhile, in practice, a convention has also spread that interprets VO in the broad sense of a data holder, independent of the definition above, and calls carrier objects with nothing but getters and setters VOs. The main source that spread this convention is examined in the Core J2EE Patterns section below.

In Fowler’s original definition, a DTO is an object meant to reduce the cost of remote calls. The catalog for Martin Fowler’s Patterns of Enterprise Application Architecture defines a DTO as follows.

The same definition appears on page 401 of the book. Every remote call costs a network round trip and serialization, so the pattern grew out of the intent to deliver all the needed data in a single call. For example, instead of fetching a customer’s name, address, and order list with three remote getter calls, you receive a single DTO holding all three values in one call.

Objects that hold data crossing the network, such as HTTP API requests and responses, fit this definition in that they cross a process boundary and are serialized. Not every HTTP API is designed to reduce the number of remote calls, however, so calling these objects DTOs extends the original definition to modern API boundaries.

In practice the definition has been stretched further. A convention has emerged of calling any object that carries data across layer boundaries within the same process a DTO, with no remote call involved. Examples include objects holding DB query results, objects passed from the service layer to the view rendering layer, and response-only objects converted from JPA entities so that the entities are not exposed directly outside the service layer. This usage is far from the original definition of reducing the number of remote calls, so one could argue that such objects are hard to call DTOs.

Apart from the debate over the name, one can also ask whether having such objects in a local context is desirable from a design standpoint. In LocalDTO, Fowler takes issue not with the name but with this usage. His starting point is that the DTO pattern exists to reduce the cost of remote calls, so in a local context with no remote calls that reason disappears. He therefore says that in a local context DTOs are not just unnecessary but actually harmful. The reasons are that a coarse-grained API that exchanges a lot of data in a single call is awkward to use, and that all the work of moving data from the domain layer or data source layer into DTOs is added cost.

To the argument that DTOs should be placed in the service layer API so that the service layer’s clients do not depend on the domain model, he replies that this may be convenient but is not worth all the cost of the data mapping.

In the same article, however, he acknowledges that something like a DTO is useful even locally when there is a large gap between the presentation layer’s model and the domain model.

In such cases the mapping between the two models is needed anyway, so the DTO is not an added cost. Later in the same article he also adds the use of DTOs for exchanging data as messages between isolated areas in a multithreaded application. In short, Fowler’s criticism is aimed at DTOs introduced for the sake of separation from the domain model itself. It does not reject cases where there is a real need, such as a mismatch between models or message passing between isolated areas.

The naming debate and the usage debate are different questions, but they start from the same premise. The fact that a local context has no remote calls serves, on one side, as grounds that the name DTO does not match the original definition, and on the other, as grounds that the reason to have a DTO grows weak. The role-based suffixes I propose later are an answer to the naming debate. Whether to have such an object at all is a matter to settle separately in the usage debate, and if you decide to have one, the proposal is to give it a name that reveals its role rather than Dto.

In the end, the criterion for distinguishing a VO from a DTO is the object’s characteristics and role. Representing a value concept and judging equality by value is a property of a VO; carrying data across a boundary is the role of a DTO. The two are not mutually exclusive categories. An immutable DTO with value equality is also a VO. Conversely, not every DTO needs value equality.

In the Java/J2EE (now Jakarta EE) community, a prominent early source that spread the conflation of the two terms is Core J2EE Patterns: Best Practices and Design Strategies by Deepak Alur and others. The first edition, published in 2001, defined an object that transfers data between tiers as a pattern named Value Object. The second edition in 2003 renamed the same pattern TO (Transfer Object). The rename appears intended to avoid confusion with the Value Object as a value-equality object. Martin Fowler calls the pattern with the same role a DTO (Patterns of Enterprise Application Architecture, p. 401). In short, the following three refer to the same transfer pattern.

Oracle’s Transfer Object documentation describes this pattern under the renamed name, Transfer Object.

Several other books also wrote that VO and DTO mean the same thing or are very close concepts.

I cannot say for certain that all of these books were directly influenced by the first edition of Core J2EE Patterns. But given when they appeared and the phrasing repeated across the literature, I suspect the first edition’s usage had some influence on the wording of later Java/J2EE literature. More than twenty years after the second edition changed the name, the practice remains.

You might wonder whether a name already in common use within a team really needs to change. But the practice of calling data carrier objects VOs has a real cost, because the Value Object as a value-equality object keeps appearing in three contexts: DDD, ORM, and Java language and JVM features.

If you understand a VO as a data holder with nothing but getters and setters, the terminology clashes when you read these materials, and confusion follows. For example, reading an explanation that says to map a VO as an @Embeddable, you picture a request parameter object full of setters. Calling a data carrier object that crosses a remote process boundary a DTO connects naturally both with Fowler’s definition and with the renamed name used since the second edition of Core J2EE Patterns.

As seen in the DTO definition section above, recent convention also uses DTO in the broad sense of a data holder that crosses a layer boundary. But attaching the DTO suffix to every carrier object has a drawback. If objects holding HTTP request parameters and objects holding the results of statistics queries are all called DTOs, the name alone does not reveal the role. For example, from the name IssueDto alone you cannot tell whether it is a request body, a lookup response, or the result of a statistics query.

I recommend dividing suffixes by the object’s role. The name then reveals the role on its own, and you also avoid the debate over departing from the strict definition when objects used in layers unrelated to remote calls are called DTOs. Here are some example names.