Another interesting and quite common question relates to immutable domain classes.
Let’s take an example. Let’s say that we have a list of countries that our system supports. Each country is represented with the following domain class:
public class Country
{
public long Id { get; }
public string Name { get; }
public Country(long id, string name)
{
Id = id;
Name = name;
}
}
Notice that this class is immutable. Is it an Entity or is it a Value Object in the Domain-Driven Design taxonomy?
I wrote about the differences between Entities vs Value Objects in detail in this article, but here’s a diagram with the summary of that article:
![[Enable Images]](https://khorikov.org/images/2021/2021-02-09-entity-vs-value-object.png)
One of the most famous differentiating factors of Value Objects is that they are always immutable. And so, given that the Country is also immutable, does it make it a Value Object?
No, it doesn’t. Country here is an Entity, not a Value Object.
The single, most foundational difference between Entities and Value Objects is the presence of an identifier. All other differences are mere implications.
Entities, in fact, can and quite often are immutable too, and that doesn’t make them Value Objects.
The difference is, once again, whether or not it has an Id field. If it does, it means that we care about this object’s identity, which automatically makes it an entity.
A value object in the above example would be the country name or the country Id (we can introduce separate Value Object classes for them), but not the Country itself.
--Vlad
Enjoy this message? Here are more things you might like:
Workshops — I offer a 2-day workshop for organizations on Domain-Driven Design and Unit Testing. Reply to this email to discuss.
Unit Testing Principles, Patterns and Practices — A book for people who already have some experience with unit testing and want to bring their skills to the next level.
Learn more »
My Pluralsight courses — The topics include Unit Testing, Domain-Driven Design, and more.
Learn more »