The most common kinds of objects in a domain model are entities and values. Entities represent domain entities such as people, devices, events, documents, procedures, etc. An entity can have attributes such as volume, weight, temperature, size, color, expiration date, etc. These are values.
The identity of a value is determined by its attributes, while the identity of an entity is determined by the domain entity it represents. Thus, two entities are equal if they represent the same domain entity, while two values are equal if they have the same attributes.
Entities are usually mutable—their attributes can change without changing their identity. Thus, even when the balance of my bank account goes down, it still represents my bank account. Values are usually immutable, their attributes don't change. For example, if I change the amount attribute of a value object representing the distance "7 miles" to 10 it now represents an entirely different value.
Entities and values are usually serializable. They can live in memory, files, or databases.
Entities usually have unique identification "numbers" to simplify the task of determining when two entities are equal.
Having multiple entities representing the same domain entity
can lead to synchronization problems. Allowing values to be mutable can also
lead to problems since values can be shared.
An inventory system for a car dealership might include the
following fragment:
Notice that cars have a unique vehicle identification
number. This will make it easy to determine if two instances of car are equal.
Cars can share colors because colors are immutable values. If we repaint a car
from red to blue, we create a new instance of the Color class representing blue
rather than change attributes of the red color. (After all, colors can be
shared.)
The following object diagram shows to red cars:
We frequently need to define equals, hashCode,
toString, and other administrative functions (but not
setters) for values. For example: Color.java.