Domain-Driven Design: Tackling Complexity in the Heart of Software

However, if we think of this category of object as just the absence of identity, we

---

haven't added much to our toolbox or vocabulary. In fact, these objects have
characteristics of their own and their own significance to the model.
These are the
objects that describe things.
An object that represents a descriptive aspect of the domain with no conceptual identity is called a
VALUE OBJECT
. V
ALUE OBJECTS
are instantiated to represent elements of the design that we care
about only for 
what
they are, not 
who
or 
which
they are.
Is "Address" a V
ALUE
 O
BJECT
? Who's Asking?
In software for a mail-order company, an address is needed to confirm the credit card,
and to address the parcel. But if a roommate also orders from the same company, it is
not important to realize they are in the same location. Address is a 
VALUE OBJECT
.
In software for the postal service, intended to organize delivery routes, the country
could be formed into a hierarchy of regions, cities, postal zones, and blocks, terminating
in individual addresses. These address objects would derive their zip code from their
parent in the hierarchy, and if the postal service decided to reassign postal zones, all
the addresses within would go along for the ride. Here, Address is an 
ENTITY
.
In software for an electric utility company, an address corresponds to a destination for
the company's lines and service. If roommates each called to order electrical service,
the company would need to realize it. Address is an 
ENTITY
. Alternatively, the model
could associate utility service with a "dwelling," an 
ENTITY
with an attribute of address.
Then Address would be a 
VALUE OBJECT
.
Colors are an example of 
VALUE OBJECTS
that are provided in the base libraries of many modern
development systems; so are strings and numbers. (You don't care which "4" you have or which
"Q".) These basic examples are simple, but 
VALUE OBJECTS
are not necessarily simple. For example,
a color-mixing program might have a rich model in which enhanced color objects could be
combined to produce other colors. These colors could have complex algorithms for collaborating to
derive the new resulting 
VALUE OBJECT
.
A 
VALUE OBJECT
can be an assemblage of other objects. In software for designing house plans, an
object could be created for each window style. This "window style" could be incorporated into a
"window" object, along with height and width, as well as rules governing how these attributes can
be changed and combined. These windows are intricate 
VALUE OBJECTS
made up of other 
VALUE
OBJECTS
. They in turn would be incorporated into larger elements of a plan, such as "wall" objects.
V
ALUE OBJECTS
can even reference 
ENTITIES
. For example, if I ask an online map service for a
scenic driving route from San Francisco to Los Angeles, it might derive a Route object linking L.A.
and San Francisco via the Pacific Coast Highway. That Route object would be a 
VALUE
, even though
the three objects it references (two cities and a highway) are all 
ENTITIES
.
V
ALUE OBJECTS
are often passed as parameters in messages between objects. They are frequently
transient, created for an operation and then discarded. V
ALUE OBJECTS
are used as attributes of
ENTITIES
(and other 
VALUES
). A person may be modeled as an 
ENTITY
with an identity, but that
person's 
name
is a 
VALUE
.