In Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans, Entity and Value Types are 2 of the fundamental building blocks that the concepts in the rest of the book are built on. Let's take a look at what they are and why they matter.

Entities

In DDD, an Entity is something that has an identifier and an owner. It can be mutable, but has a thread of continuity throughout its lifetime. Let's break that down using a car as an example:

1. An Entity has an identifier: A good example of an Entity is a car, which is identified by its license plate.

2. An Entity has an owner: If a car gets a parking ticket, or is involved in an accident, the authorities can find out who owns the car by looking at records that map a car to its owner. The owner can sell the car and transfer ownership to somebody else. The owner can also acquire a new car.

3. An Entity can be mutable: An owner can change things on a car. They can change the wheels, the tires, the colour of the car, the engine and other parts. They can extend the car with body kits.

4. An Entity has a thread of continuity: To return to the parking ticket example, if the car has changed owners, authorities can tell who owned a car at the point in time the ticket was written. Similarly there might be significant, time-based events recorded about a car such as if it was involved in a serious accident or if it has been changed in a significant way, for instance the introduction of a souped up, turbo-charged engine.

Value types

In DDD, a Value type is something that is immutable, has no identifier, and is replaceable by another instance of the same Value type. We are often concerned with the quantity of a Value type rather than specific instances. To carry on with the car analogy, let's consider tyres as being a Value type.

1. A Value type is immutable: A tyre is made up of a rubber compound and is moulded into a shape. the ingredients of the rubber compound and the shape of the tyre will never change once the tyre leaves the factory. Even if the manufacturer changes its rubber compound, this only changes future instances of tyres not ones that already exist and are fitted on cars.

2. A value has no identifier: A car has a number of tyres on it. Tyres can be moved from one car to another, but there is no way of tracing which car a tyre was on at any particular time as there is nothing to identify an individual tire or to trace an owner.

3. A Value type is replaceable by another instance of the same Value type: Changing the tire on a car with another tire of the same make and model will not change the car. Similarly, if a mechanic has 10 of the same tire in stock, it does not matter to the car owner which tire the mechanic takes from the shelf and puts on the car. They are essentially all the same.

Context matters

This is where it gets a little more complicated, because it isn't as simple as saying something is always an Entity or always a Value type. As is often the case in DDD, context is always important.

Money can be a good example of a Value type. It does not normally matter if a £5 note is the same £5 note. It is the quantity you have that matters, not the instance of the note. This is true in most contexts but if we think about a bank robbery, each note has a serial number and serial numbers are tracked to some degree. We might not know exactly who has a note at a particular time but there are times when serial numbers are used to identify an instance and owner of a note. For police investigating a bank robbery and looking for £5 notes with specific serial numbers, those notes are Entities rather than Value types.

Why does it matter?

Software models the real world, and the real world is complex. We can limit that complexity to some extent by being explicit about what is an Entity that we need to track and audit, and what is a Value type that we are only really interested in the quantity or value of. The more we can explicitly limit to be Value types the simpler our software systems will be to create and maintain. Similarly, a lot of the complexity of Entities such as identifying instances, ownership, maintaining state, and auditing changes can be quite generic and re-usable across all Entities in a system.

Where to start

If you want to find out more or start modelling software as an Entities and Value types, I'd recommend reading Eric Evans original book Domain-Driven Design: Tackling Complexity in the Heart of Software to get a good understanding of the key concepts. Beyond that, there are more modern book for most languages that suggest ways to implement Evan's concepts. A good one for .NET developers is Hands-On Domain Driven Design with .NET Core by Alexy Zimarev.