Entities vs. Value Objects

Stories and stories have been written about the benefits of using Domain Driven Design in complex systems. One of the main parts of DDD is to use Entities and Value objects instead of plain simple anemic property bags.

In this article we will discuss Entities and Value objects. We will talk about the concept and benefits of the usage of them.

Photo by Jens Lelie on Unsplash

In the real world there are some things that will never change. For instance your identity. I am not talking about your name, because you could indeed change your name. I am talking about your identity, meaning you as your being. You are unique in the whole world. We could say, everything that has a “history” and the ability to change, is an entity.

In the contrary, everything that is defined purely by it’s properties and only this properties-snapshot is important in a specific context, is called a value object.

Let’s do an example:
Consider a person, Bob. Bob has a first name, a last name and a birthday.
Now consider another person, also named Bob. Bob has also the same first name, last name and birthday.
Are these two persons the same person? Well, no! Even if their properties (or the properties that we cared) are the same, these two Bobs are definitely not the same person. They have identity. A person is in this context hence an entity.

Let’s do another example:
You go to the retail store and buy something. The cashier wants 5$. You give him 5$ in 2$, 2$ and 1$. The cashier does only care about the total amount that you give him and not about the individual bank notes he receives. Money is defined only as the underlying buying power it provides. In this context, money is a value object.

Photo by Clay Banks on Unsplash

But what if you are a rare notes collector and are searching for a very specific 5$ note. Then, you would care about the identity of the bank note itself.

What we observed now, is not a weird special case. It’s very common that an entity can be a value object and vice-versa when we are talking about DDD.

The reason for this behavior is a different domain environment. When we use DDD, we have to make sure that we understand the underlying business domain. A separation of a big domain in multiple subdomains is also useful, since different subdomains can have different rules and a different language.

Photo by Tingey Injury Law Firm on Unsplash

An object will be a value object, if in a specific context, the semantics of it are completely specified by the properties of this object. If an object needs to have a history and a lifecycle, you would want to create an entity.

Why you should use Entities and Value Objects

Entities and Value Objects are popular in DDD, but you can also use them without dogmatically applying DDD.
Especially Value Objects are very useful. They have several benefits including:

1. Domain concepts made explicit
   By creating Value Objects, you create types that improve the readability and the knowledge transfer of your software. It enables teams across department boundaries to speak the same ubiquitous language.
2. Compile time tests and better code quality
   If you start using value objects in your software project, you will notice far fewer bugs. The correctness of behaviors of your system will improve, because you control the creation process of value objects. By using an always valid value object approach, you will not have to worry that some weird requirement that you considered to be implicit as given is true. You can control the instantiation of the value object and hence, you have the power to deny the creation of it, if the creation is contradicts the invariants of your bounded context.
   By using value objects as parameters, you can be sure that the the argument that is given to a function is valid and focus on the implementation of the functionality.
3. Simple code
   Domain knowledge can be embedded inside the value object, such that every user of that value object has the same understanding of the semantics of it. By centralizing the domain behavior of that object inside a class, you create a single source of truth and a common understanding of the expected behavior.
   Also, because Value Objects should be immutable, you’ll always know that an update of a value object property in an entity, is done with a new creation of a value object with the desired properties and then a simple assignment instead of searching for a particular update method in the entity.

Entities on the other hand have their own benefits:

1. Predefined transaction context
   An entity can provide a transaction context for a specific domain process. Since every entity has an aggregate root (see DDD), all entities beneath the entity tree of the root, will be saved atomically. This in turn helps with the consistency of the whole system.
2. Business oriented software architecture
   If you follow the DDD paradigm and create entities that match real-life processes and objects, you will accelerate your development time. Simply by grouping coherent domain objects you will gain useful domain knowledge and create powerful mental models of the business processes.

In short, entities and value objects are great tools that help you write clean code and provide clear semantics with very high signal to noise ratio. They also help standardizing workflows and code structure.

Don’t forget to subscribe :)
Cheers!