Entity

An entity is an object defined by identity and continuity rather than by its attributes: a customer can change name, address, and email and still be the same customer. The model has to say what same means, usually a stable identifier with equality based on it alone.

Read through intent and mechanism, the intent was never walked back: Evans’s 2015 Reference keeps the pattern essentially verbatim. What aged is the word. JPA’s @Entity taught a generation that an entity is whatever the ORM persists, and Clean Architecture uses the same word for a third thing, so “entity” in a design conversation now needs disambiguation. The DDD meaning is the narrow one: an identity the domain itself tracks through change, not a row with a primary key.

The practical caution is overuse. Vernon blames it on the pull of databases and persistence frameworks, and the field’s default runs the other way: prefer a value object wherever possible and reserve entities for the few things the domain genuinely follows over time. Most entities then live inside an aggregate, and the root’s identity is the one the outside world holds onto.

class Order(val id: OrderId) {
  override fun equals(other: Any?) = other is Order && other.id == id
  override fun hashCode() = id.hashCode()
}

Signal: the domain keeps referring to the thing after every attribute has changed. Part of Domain-Driven Design.

Sources

• Eric Evans, Domain-Driven Design Reference (2015): keeps the entity pattern essentially verbatim from 2003.
• Robert C. Martin, The Clean Architecture (2012): uses “entity” for the enterprise-business-rules layer, the third sense that makes the DDD term need disambiguation.
• Vaughn Vernon, Implementing Domain-Driven Design (2013): blames entity overuse on the pull of databases and persistence frameworks, and argues to prefer value objects.