Entity
A domain object defined by its unique identity that persists through time and state changes, rather than being defined by its attributes.
Also known as: Domain Entity, DDD Entity
Category: Software Development
Tags: domain-driven-design, software-design, patterns, modeling, software-engineering
Explanation
An Entity in Domain-Driven Design is a domain object that is fundamentally defined by its identity rather than its attributes. While a value object is interchangeable with any other instance that has the same values, an entity has a unique identity that distinguishes it from all other objects—even those with identical attributes.
**The identity principle:**
Consider two people named 'John Smith' living at the same address. They have identical attributes, but they are clearly different people. Each has a persistent identity (perhaps a Social Security Number, employee ID, or database primary key) that distinguishes them. This is the essence of an entity: identity matters more than attributes.
**Key characteristics:**
- **Unique identity**: Each entity has an identifier that distinguishes it from all others of the same type
- **Continuity over time**: An entity maintains its identity even as its attributes change (a Customer who changes their name or address is still the same Customer)
- **Mutable state**: Unlike value objects, entities can and do change their attributes over time
- **Lifecycle**: Entities are created, modified, and eventually archived or deleted—they have a meaningful lifecycle
**Common examples:**
- **Customer**: Identified by customer ID, even if name, email, or address changes
- **Order**: Identified by order number, persists through status changes (Pending → Confirmed → Shipped → Delivered)
- **BankAccount**: Identified by account number, balance changes over time
- **Employee**: Identified by employee ID, role and department may change
**Design guidelines:**
- **Focus on identity**: Define what makes each entity unique and ensure that identity is immutable
- **Minimize attributes**: Keep entities lean. Move descriptive attributes into value objects where possible
- **Encapsulate behavior**: Entities should contain the business logic that governs their state transitions
- **Aggregate membership**: Entities are typically part of an aggregate, with one entity serving as the aggregate root
**Entity vs. Value Object:**
Choosing between entity and value object is one of the most important modeling decisions in DDD. Ask: 'Do I need to track this specific instance over time?' If yes, it's an entity. If two instances with the same attributes are interchangeable, it's a value object.
Related Concepts
← Back to all concepts