An object defined primarily by its identity is called an ENTITY.

An object that represents a descriptive aspect of the domain with no conceptual identity is called a VALUE OBJECT.

These two definitions are taken from the book Domain-Driven Design written by Eric Evans. They are quite helpful concepts when modelling objects. An entity requires an identity and some sort of continuity. A user object, for example, is an entity. It’s created at a certain point in time, retrieved from a data store when needed, and can be updated when a user attribute changes. A value object, on the other hand, is an object that we create, use, and discard as soon as we’re done with it. To change a value object, we need to destroy and recreate. They don’t have continuity.

While immutability may describe the main difference between entities and value objects, I find Dan Abramov’s mental model for Values great to explain the difference. In his “Just Javascript” course, he makes an analogy of a universe where primitive values are distant stars. You cannot reach them and alter them, but you can point to them. An obvious example of a primitive value is an integer. Let’s consider the integer value of 42. If you have a variable whose value is 42, according to the analogy, your variable points to a star called 42. If you want to change the variable’s value from 42 to 43, you can’t change the star, but rather you start pointing to a different star, which is 43. In either case, Abramov explains, those stars exist. They’re already there, unchangeable, waiting for us to point to them.

Following the same analogy, value objects are also unchangeable, i.e., immutable. They exist on their own. We point to them only if we need them at any given point; we don’t care about them otherwise. If we’d like to change or update a value object, we simply stop pointing at it, and look for another star. What happens in the background, of course, is that we create a new value object to use, and the old one gets picked up by the garbage collector.

A major advantage of having and using value objects compared to having all the data on the entities is to create side-effect free code. When we don’t mess with the state of an entity, but rather extract what’s needed into a value object, we give ourselves an immutable object to operate on. The value object in our code does not have to be technically immutable. Since we won’t operate on our entity and the value objects can be discarded, the risk of accidental updates on our entity comes down to zero.