What's an Entity, Anyway? - EventSourcingDB

Skip to content

Initializing search

Getting Started

Fundamentals

Deployment and Operations

Reference

Client SDKs

Extensions

MCP Server

Best Practices

Implementation and Development

Data Management and Performance

Operations, Compliance and Infrastructure

Common Issues

Blog

Categories

Privacy Policy

Legal Notice

What's an Entity, Anyway?¶

I've worked with Domain-Driven Design for fifteen years, and I'll admit something I usually keep to myself. There's one concept in DDD whose point I've never quite gotten. Not because I haven't read Evans, and not because I haven't built systems around it. I've done both. But every time I sit with the concept of the Entity and ask myself what it's actually for, I come away with the same shrug. Value Objects feel intuitive. Aggregates feel intuitive. The Entity feels like a placeholder that everyone agreed to keep teaching anyway.

A conversation a few days ago finally produced the click I'd been waiting for, and the answer surprised me. The confusion wasn't a personal blind spot. The concept itself has been quietly hollowed out by the very ideas that surround it , and most of us keep teaching it as if that hadn't happened. The Entity isn't broken. It's overshadowed. And the shadow only lifts once you start asking what would happen if the thing casting it weren't there.

The Concept That Wouldn't Click¶

Let me set the scene. When I introduce someone to DDD, the building blocks come in roughly this order, and they land with roughly the following weight. A Value Object is a thing defined by its values. Two of them with the same data are indistinguishable, like an Address or a Money amount. Most developers nod at this immediately, because it's the same concept as a struct, a record, or an enum in their favorite language. They've already been doing it for years.

An Aggregate is a consistency boundary: a cluster of related objects that get loaded together, saved together, and that protect their invariants together. Once you've seen one race condition you couldn't reason about, you start to feel the appeal. The Aggregate gives you a unit of work that has a clear inside and a clear outside, and you can talk about it without ambiguity.

Then comes the Entity , and that's where the lecture, the textbook, and, in my case, the inner monologue all get a little quiet. An Entity, the definitions go, is a thing with identity that persists over time. Two Entities with identical data are still two different Entities, because identity matters more than data. The example everyone reaches for is a bank transaction, or a person, or some object whose continuity through change is the point. It sounds reasonable in isolation. But the moment I try to use the concept in actual modeling, it dissolves into something else , and I can't find the place where it does its own work.

What an Entity Was Originally Supposed To Be¶

I want to be fair to the concept. In the original framing, the Entity was doing real work. Evans introduced it as the answer to a specific question: what do you call something whose identity matters more than its current data? An account whose balance changes, but is still the same account. A book whose location moves around a library, but is still the same book. A patient whose chart fills up over years, but is still the same patient.

That part makes sense. There's a clear distinction between what something is and which one it is. The Entity captures the which, and the Value Object captures the what. Two transactions for the same amount on the same day are still two distinct events in the world, even if they look identical on a screen. The Entity is the modeling concept that lets you say "these are two, not one." That's a real job.

It's also, I now think, the only job that was ever uniquely the Entity's. And once you start introducing the rest of the DDD vocabulary, that job stops being uniquely hers.

Then the Aggregate Showed Up¶

Here's what happens the moment you accept the Aggregate as a first-class concept. The Aggregate becomes the thing that's loaded, the thing that's persisted, the thing that's addressed from the outside by an ID. The Aggregate is where the invariants live, because it's the consistency boundary. The Aggregate is what gets versioned, what gets concurrency-checked, what gets snapshotted if you go that route. When somebody says "send a command to this account," they mean the Account Aggregate, identified by its Aggregate Root's ID.

What's left for the Entity? A thing with a local ID inside the Aggregate. That's not nothing. But it's a lot less than the bold introduction promised. We started with "the modeling concept for things whose identity matters more than data," and we ended with "an internal element of an Aggregate that happens to need an ID for addressing." The first one is a philosophical claim about how to think about the world. The second is an implementation...