Low-Level DesignEntities, Attributes, and Behaviors

Entities, Attributes, and Behaviors

LevelBeginner

Duration60 mins

TopicEntities, Attributes, and Behaviors

1 / 4

Understanding Entities — The Building Blocks of Your System

What Exactly Is an Entity?

Every software system models some aspect of the real world—or at least a simplified, useful abstraction of it. Whether you're building an e-commerce platform, a banking application, a social network, or a video game, you're representing things from your problem domain as objects in code.

These "things" are what we call entities. They are the nouns of your system, the concepts that have identity, meaning, and purpose. Understanding entities deeply is the first step toward designing systems that are both intuitive and maintainable.

What You Will Learn

By the end of this page, you will understand what entities are, how to identify them from problem descriptions, and why getting entities right is foundational to all subsequent design decisions. You'll develop the skill to see through problem complexity and extract the core concepts that will become your classes.

The Concept of an Entity

An entity is a distinct, identifiable concept from your problem domain that has meaning independent of its properties. In simpler terms, an entity is a "thing" that:

Has identity — Even if all its properties change, it remains the same entity
Has relevance — It matters to your problem domain and business logic
Has continuity — It persists over time and across operations
Can be distinguished — You can tell one instance from another

Let's be precise about what this means.

Entity vs. Value: The Identity Test

Ask yourself: "If I swap all the properties of object A with object B, have they become each other, or are they still distinct?" For entities like User or Order, swapping properties doesn't swap identity—Alice is still Alice even if she changes her name. For value objects like an Address or Money, identity IS the properties—$50 is $50 regardless of which specific instance you hold.

Identity is the defining characteristic of an entity.

Consider a User in a social media application:

The user has a unique ID (let's say user_12345)
They can change their email, name, profile picture, bio—everything
But they are still user_12345, the same account, the same entity
Their followers still follow them, not their current set of properties

This persistence of identity through change is what makes something an entity. It's also why entity design is critical: entities form the stable backbone around which your system's behavior is organized.

Entity Characteristics
Characteristic	Description	Example
Unique Identity	Each instance can be uniquely identified, typically by an ID	User ID, Order Number, Transaction ID
Lifecycle	Entities are created, modified, and potentially destroyed over time	An order is placed, shipped, delivered, or cancelled
Mutable State	Properties can change while identity remains constant	User changes email, product changes price
Domain Significance	Entities represent core business concepts	Customer, Invoice, Appointment, Reservation
Trackability	History and changes can be tracked over time	Audit logs, versioning, change history

Entities in Domain-Driven Design

The concept of entities is central to Domain-Driven Design (DDD), a software design philosophy that emphasizes building software models that closely mirror real-world domains. In DDD terminology, entities are one of the fundamental building blocks, alongside Value Objects, Aggregates, and Services.

While we'll explore these other concepts later, understanding the DDD perspective on entities provides valuable insight:

"An entity is an object that is defined not by its attributes, but by a thread of continuity and identity." — Eric Evans, Domain-Driven Design

This definition captures the essence: entities are about continuity and identity, not about their current state.

DDD Entity Principles

•Model entities around business identity — Use the same identifiers the business uses. If the business talks about 'Order Number ORD-12345', your Order entity should too.
•Keep entity identity simple and stable — Once assigned, identity shouldn't change. Complex composite keys often signal a design that needs rethinking.
•Define equality based on identity — Two User objects with the same ID are the same user, even if instantiated separately or with outdated data.
•Don't confuse database identity with domain identity — Auto-increment IDs are implementation details; business-meaningful identifiers are design decisions.
•Protect entity invariants — Entities should enforce their own consistency rules. An Order that allows negative quantities isn't a well-designed entity.

DDD Isn't Just for Complex Systems

While DDD is often associated with complex enterprise systems, its entity concepts apply universally. Even simple CRUD applications benefit from thinking clearly about which concepts are entities versus value objects, and how identity should work across your domain.

Identifying Entities from Problem Statements

One of the most critical skills in Low-Level Design is the ability to read a problem description and identify the core entities. This isn't just about finding nouns—it's about recognizing which nouns represent concepts central to your domain.

Let's explore a systematic approach to entity identification.

The Noun Extraction Method (and Its Limitations)

A classic technique is to underline all nouns in a problem statement. While this is a reasonable starting point, not all nouns become entities:

Some nouns are attributes of other entities (e.g., "name" is a property of Person)
Some nouns are value objects without distinct identity (e.g., an Address)
Some nouns are incidental to the domain (e.g., "user" mentioned in context)
Some nouns are roles or relationships rather than entities (e.g., "manager")

The skill lies in filtering this initial list down to true entities.

Questions to Identify True Entities

•Does it have unique identity? Can you have multiple instances that need to be distinguished? Would two instances with the same properties still be different things?
•Does the business track it over time? Do users/stakeholders refer to specific instances? 'Order #12345', 'Customer John Doe', 'Invoice INV-2024-001'?
•Does it have its own lifecycle? Can it be created, modified, and potentially deleted independently? Does it go through states?
•Is it a first-class concept? Do people in the domain talk about it as a "thing"? Or is it just a property of something else?
•Would removing it break the domain? Is this concept fundamental to understanding the problem?

Worked Example: Online Bookstore

Consider a requirement: "Users can browse books, add them to a shopping cart, and place orders. Each order contains multiple items and is shipped to a delivery address."

Let's identify the nouns:

Users, books, shopping cart, orders, items, delivery address

Now let's analyze each:

Entity Identification Analysis
Noun	Entity?	Reasoning
User	✓ Yes	Has unique identity (user ID), tracked over time, has lifecycle (registration to deletion)
Book	✓ Yes	Has unique identity (ISBN/book ID), cataloged independently, persists across orders
Shopping Cart	✓ Maybe	Could be an entity (persisted cart) or a transient collection. Design decision based on requirements.
Order	✓ Yes	Has unique identity (order number), clear lifecycle (pending→confirmed→shipped→delivered), tracked historically
Order Item	✓ Entity/VO	Has identity within an order, but may not exist independently. Often modeled as a child entity of Order.
Delivery Address	✗ Value Object	Typically no identity—defined entirely by its properties. May be copied, not referenced.

Gray Areas Are Design Decisions

Notice how Shopping Cart and Order Item have nuanced answers. This is normal. Whether something is an entity, a value object, or a mere attribute often depends on your specific requirements. The key is to make conscious decisions, not accidental ones.

Entity Modeling Patterns

As you gain experience, you'll notice recurring patterns in how entities are structured and related. Recognizing these patterns accelerates your design process and helps you avoid common pitfalls.

Let's examine several fundamental entity modeling patterns:

Pattern 1: Root Entities and Child Entities

Some entities serve as "roots" that own and manage other entities. The root provides a consistency boundary—operations on child entities go through the root.

Example: An Order (root) contains OrderItems (children). You don't create or modify OrderItems independently; you add/remove them through the Order. This pattern is formalized in DDD as an Aggregate.

Root Entity Pattern
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
// Order is the root entity (aggregate root in DDD terms)
class Order {
    private readonly id: string;
    private items: OrderItem[] = [];
    private status: OrderStatus = OrderStatus.Draft;
    
    constructor(id: string, customerId: string) {
        this.id = id;
        this.customerId = customerId;
    }
    
    // Child entities are managed through the root
    addItem(product: Product, quantity: number): void {
        // Root enforces business rules
        if (this.status !== OrderStatus.Draft) {
            throw new Error("Cannot modify confirmed order");
        }
        
        const existingItem = this.items.find(i => i.productId === product.id);
        if (existingItem) {
            existingItem.increaseQuantity(quantity);
        } else {
            this.items.push(new OrderItem(product.id, product.price, quantity));
        }
    }
    
    confirm(): void {
        if (this.items.length === 0) {
            throw new Error("Cannot confirm empty order");
        }
        this.status = OrderStatus.Confirmed;
    }
}
 
// OrderItem is a child entity within the Order aggregate
class OrderItem {
    private readonly productId: string;
    private readonly unitPrice: Money;
    private quantity: number;
    
    constructor(productId: string, unitPrice: Money, quantity: number) {
        this.productId = productId;
        this.unitPrice = unitPrice;
        this.quantity = quantity;
    }
    
    increaseQuantity(amount: number): void {
        this.quantity += amount;
    }
    
    get total(): Money {
        return this.unitPrice.multiply(this.quantity);
    }
}

Pattern 2: Reference Entities vs. Embedded Data

When entities relate to each other, you have a choice: reference by ID or embed the related data.

Reference by ID: Order stores customerId, not the entire Customer object. Advantages: data stays consistent, entities remain independent.
Embed relevant snapshot: Order might embed a shipping address copy rather than referencing a mutable Address entity. Advantages: historical accuracy, no cascade issues.

Reference by ID

•Use when the related entity is independently managed
•Use when you always want current data
•Examples: Order references customerId
•Common for many-to-one relationships

Embed Snapshot

•Use when historical accuracy matters
•Use for value objects without identity
•Examples: Order embeds shipping address at time of purchase
•Common for auditing and historical records

Pattern 3: State-Based Entities

Many entities have explicit states that govern their behavior. An Order might be Draft, Confirmed, Paid, Shipped, Delivered, or Cancelled. A User might be Pending, Active, Suspended, or Deleted.

State-based design means:

Different states allow different operations
State transitions follow defined rules
The entity enforces its own state machine

State Machine Discipline

If your entity has states, document the valid transitions. An order can go from Confirmed to Shipped, but not from Delivered back to Draft. Violating state invariants is a common source of bugs in complex systems.

Common Mistakes in Entity Design

Entity design seems straightforward until you've made these mistakes a few times. Let's examine the most common pitfalls and how to avoid them.

Entity Design Anti-Patterns

•Anemic Entities — Entities that are just data bags with getters/setters, where all behavior lives elsewhere. This scatters related logic and makes the domain model unintelligible. Entities should encapsulate behavior, not just data.
•God Entities — Entities that do too much, containing every conceivable property and method. A User entity shouldn't handle authentication, authorization, profile rendering, notification preferences, and billing. Split responsibilities.
•Identity Confusion — Using mutable properties as identity (e.g., email as user ID), composite keys that are hard to manage, or auto-increment IDs treated as business identifiers. Keep identity simple, stable, and meaningful.
•Ignoring Invariants — Allowing entities to exist in invalid states (negative quantities, end date before start date, empty required fields). Entities should validate their invariants on construction and state change.
•Bi-directional References Everywhere — Making every relationship navigable in both directions. This creates tight coupling and makes it hard to reason about changes. Prefer unidirectional references.
•Confusing Entities with Database Tables — Designing entities as direct mirrors of database schema. Entities are about domain concepts, not storage. The mapping can be different.

Anemic vs Rich Entity
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// ❌ ANTI-PATTERN: Anemic Entity (just data, no behavior)
class AnemicOrder {
    public id: string;
    public items: OrderItem[] = [];
    public status: string;
    public customerId: string;
    public total: number;
    // All getters/setters, no business logic
}
 
// Someone else has to validate business rules!
function addItemToOrder(order: AnemicOrder, product: Product, qty: number) {
    // Where do we check if order is modifiable?
    // Where are the business rules?
    // This logic is scattered across the codebase
    order.items.push({ productId: product.id, qty });
    order.total = calculateTotal(order.items);
}
 
// ✅ CORRECT: Rich Entity (encapsulates behavior)
class Order {
    private readonly id: string;
    private readonly items: OrderItem[] = [];
    private status: OrderStatus = OrderStatus.Draft;
    
    constructor(id: string, customerId: string) {
        this.id = id;
        this.customerId = customerId;
    }
    
    // Behavior lives WITH the data
    addItem(product: Product, quantity: number): void {
        if (this.status !== OrderStatus.Draft) {
            throw new InvalidOperationError("Cannot modify non-draft order");
        }
        if (quantity <= 0) {
            throw new ValidationError("Quantity must be positive");
        }
        // Encapsulated logic: find existing, update or create
        const existing = this.items.find(i => i.productId === product.id);
        if (existing) {
            existing.updateQuantity(existing.quantity + quantity);
        } else {
            this.items.push(new OrderItem(product.id, product.price, quantity));
        }
    }
    
    // Calculated property, always consistent
    get total(): Money {
        return this.items.reduce(
            (sum, item) => sum.add(item.subtotal),
            Money.zero()
        );
    }
}

The Entity Litmus Test

If you can describe what your entity IS and what it DOES in a single sentence that a domain expert would understand, you're on the right track. 'An Order represents a customer's confirmed purchase, tracks its items, calculates totals, and manages its lifecycle from creation to delivery.' Clear and behavior-rich.

Entity Design Principles

Based on the patterns and anti-patterns we've explored, here are guiding principles for designing effective entities:

Entity Design Principles

•Assign identity deliberately — Choose identifiers that are stable, unique, and meaningful. UUIDs work for most cases; business-meaningful IDs (like order numbers) work when the business requires them.
•Encapsulate invariants — If an order item's quantity must be positive, enforce it in the OrderItem class, not in external validation code. The entity should be impossible to corrupt from outside.
•Make invalid states unrepresentable — Use types to prevent mistakes. An EmailAddress type that validates format is better than a nullable string. An enum for status is better than a magic string.
•Favor immutability where possible — Properties that don't change (creation date, original ID) should be readonly. State changes should be explicit methods, not setter calls.
•Define clear boundaries — An entity should have a single, focused responsibility. If it's getting too large, consider splitting into multiple entities connected by references.
•Model lifecycles explicitly — If your entity has states, model them as a proper state machine with defined transitions and guard conditions.
•Use the domain language — Name your entities, properties, and methods using terms the domain experts use. This creates a ubiquitous language that bridges code and business.

Principles, Not Rules

These are guiding principles, not absolute rules. Context matters. Sometimes pragmatic violation of a principle is the right call. But violate them consciously, understanding the tradeoffs, not accidentally out of ignorance.

Real-World Entity Examples

Let's examine how entities manifest across different domains. This will help you develop intuition for entity identification in unfamiliar problem spaces.

Entities Across Domains
Domain	Key Entities	Key Design Considerations
E-Commerce	Customer, Product, Order, Cart, Payment, Shipment	Order lifecycle, inventory tracking, payment state machines, address handling (entity vs VO)
Banking	Account, Transaction, Customer, Card, Loan	Transaction immutability, account balance consistency, regulatory audit trails
Healthcare	Patient, Appointment, Prescription, Provider, Facility	Patient identity across systems, appointment scheduling, medication safety invariants
Social Media	User, Post, Comment, Friendship, Notification	User identity and privacy, content moderation states, relationship modeling
Ride-Sharing	Rider, Driver, Ride, Vehicle, Location	Real-time location, ride state machine, rating systems, surge pricing
Learning Platform	Student, Course, Lesson, Enrollment, Progress	Enrollment lifecycle, progress tracking, content versioning

Notice the patterns:

Every domain has core entities that represent the fundamental "things" the business deals with
Many entities have rich lifecycles (orders, appointments, rides, enrollments)
Relationships between entities are central (customers place orders, riders request rides)
Some concepts that seem like entities might be value objects (addresses, prices, coordinates)

Summary and Next Steps

We've covered the foundational concept of entities—the building blocks of your object-oriented designs. Let's consolidate the key takeaways:

Key Takeaways

•Entities are defined by identity, not properties — Even if all properties change, an entity remains the same entity as long as its identity persists.
•Entity identification is a skill — Not every noun is an entity. Apply the identity test, lifecycle test, and domain significance test to filter accurately.
•Entities should encapsulate behavior — Rich entities that enforce their invariants are more maintainable than anemic data bags with scattered validation logic.
•Patterns help structure entities — Root/child relationships (aggregates), reference vs. embedding, and state machines are recurring patterns worth mastering.
•Avoid common pitfalls — Anemic entities, god entities, identity confusion, and ignoring invariants are traps that complicate future development.
•Domain language matters — Name entities and their operations using terms that domain experts understand. This creates shared vocabulary.

What's Next:

Now that we understand entities as the core "things" in our system, we need to explore what makes them unique and describable. The next page examines attributes—the properties that describe entities, the distinction between essential and incidental attributes, and how to design attribute sets that are complete yet focused.

Page Complete

You now understand entities as the identity-bearing building blocks of your systems. You can identify entities from problem descriptions and avoid common design pitfalls. Next, we'll explore attributes—the properties that give entities their characteristics.

1 / 4

Loading learning content...

Low-Level DesignEntities, Attributes, and Behaviors

Entities, Attributes, and Behaviors

LevelBeginner

Duration60 mins

TopicEntities, Attributes, and Behaviors

1 / 4

Understanding Entities — The Building Blocks of Your System

What Exactly Is an Entity?

What You Will Learn

The Concept of an Entity

An entity is a distinct, identifiable concept from your problem domain that has meaning independent of its properties. In simpler terms, an entity is a "thing" that:

Has identity — Even if all its properties change, it remains the same entity
Has relevance — It matters to your problem domain and business logic
Has continuity — It persists over time and across operations
Can be distinguished — You can tell one instance from another

Let's be precise about what this means.

Entity vs. Value: The Identity Test

Identity is the defining characteristic of an entity.

Consider a User in a social media application:

The user has a unique ID (let's say user_12345)
They can change their email, name, profile picture, bio—everything
But they are still user_12345, the same account, the same entity
Their followers still follow them, not their current set of properties

Entity Characteristics
Characteristic	Description	Example
Unique Identity	Each instance can be uniquely identified, typically by an ID	User ID, Order Number, Transaction ID
Lifecycle	Entities are created, modified, and potentially destroyed over time	An order is placed, shipped, delivered, or cancelled
Mutable State	Properties can change while identity remains constant	User changes email, product changes price
Domain Significance	Entities represent core business concepts	Customer, Invoice, Appointment, Reservation
Trackability	History and changes can be tracked over time	Audit logs, versioning, change history

Entities in Domain-Driven Design

While we'll explore these other concepts later, understanding the DDD perspective on entities provides valuable insight:

"An entity is an object that is defined not by its attributes, but by a thread of continuity and identity." — Eric Evans, Domain-Driven Design

This definition captures the essence: entities are about continuity and identity, not about their current state.

DDD Entity Principles

•Model entities around business identity — Use the same identifiers the business uses. If the business talks about 'Order Number ORD-12345', your Order entity should too.
•Keep entity identity simple and stable — Once assigned, identity shouldn't change. Complex composite keys often signal a design that needs rethinking.
•Define equality based on identity — Two User objects with the same ID are the same user, even if instantiated separately or with outdated data.
•Don't confuse database identity with domain identity — Auto-increment IDs are implementation details; business-meaningful identifiers are design decisions.
•Protect entity invariants — Entities should enforce their own consistency rules. An Order that allows negative quantities isn't a well-designed entity.

DDD Isn't Just for Complex Systems

Identifying Entities from Problem Statements

Let's explore a systematic approach to entity identification.

The Noun Extraction Method (and Its Limitations)

A classic technique is to underline all nouns in a problem statement. While this is a reasonable starting point, not all nouns become entities:

Some nouns are attributes of other entities (e.g., "name" is a property of Person)
Some nouns are value objects without distinct identity (e.g., an Address)
Some nouns are incidental to the domain (e.g., "user" mentioned in context)
Some nouns are roles or relationships rather than entities (e.g., "manager")

The skill lies in filtering this initial list down to true entities.

Questions to Identify True Entities

•Does it have unique identity? Can you have multiple instances that need to be distinguished? Would two instances with the same properties still be different things?
•Does the business track it over time? Do users/stakeholders refer to specific instances? 'Order #12345', 'Customer John Doe', 'Invoice INV-2024-001'?
•Does it have its own lifecycle? Can it be created, modified, and potentially deleted independently? Does it go through states?
•Is it a first-class concept? Do people in the domain talk about it as a "thing"? Or is it just a property of something else?
•Would removing it break the domain? Is this concept fundamental to understanding the problem?

Worked Example: Online Bookstore

Consider a requirement: "Users can browse books, add them to a shopping cart, and place orders. Each order contains multiple items and is shipped to a delivery address."

Let's identify the nouns:

Users, books, shopping cart, orders, items, delivery address

Now let's analyze each:

Entity Identification Analysis
Noun	Entity?	Reasoning
User	✓ Yes	Has unique identity (user ID), tracked over time, has lifecycle (registration to deletion)
Book	✓ Yes	Has unique identity (ISBN/book ID), cataloged independently, persists across orders
Shopping Cart	✓ Maybe	Could be an entity (persisted cart) or a transient collection. Design decision based on requirements.
Order	✓ Yes	Has unique identity (order number), clear lifecycle (pending→confirmed→shipped→delivered), tracked historically
Order Item	✓ Entity/VO	Has identity within an order, but may not exist independently. Often modeled as a child entity of Order.
Delivery Address	✗ Value Object	Typically no identity—defined entirely by its properties. May be copied, not referenced.

Gray Areas Are Design Decisions

Entity Modeling Patterns

As you gain experience, you'll notice recurring patterns in how entities are structured and related. Recognizing these patterns accelerates your design process and helps you avoid common pitfalls.

Let's examine several fundamental entity modeling patterns:

Pattern 1: Root Entities and Child Entities

Some entities serve as "roots" that own and manage other entities. The root provides a consistency boundary—operations on child entities go through the root.

Root Entity Pattern
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
// Order is the root entity (aggregate root in DDD terms)
class Order {
    private readonly id: string;
    private items: OrderItem[] = [];
    private status: OrderStatus = OrderStatus.Draft;
    
    constructor(id: string, customerId: string) {
        this.id = id;
        this.customerId = customerId;
    }
    
    // Child entities are managed through the root
    addItem(product: Product, quantity: number): void {
        // Root enforces business rules
        if (this.status !== OrderStatus.Draft) {
            throw new Error("Cannot modify confirmed order");
        }
        
        const existingItem = this.items.find(i => i.productId === product.id);
        if (existingItem) {
            existingItem.increaseQuantity(quantity);
        } else {
            this.items.push(new OrderItem(product.id, product.price, quantity));
        }
    }
    
    confirm(): void {
        if (this.items.length === 0) {
            throw new Error("Cannot confirm empty order");
        }
        this.status = OrderStatus.Confirmed;
    }
}
 
// OrderItem is a child entity within the Order aggregate
class OrderItem {
    private readonly productId: string;
    private readonly unitPrice: Money;
    private quantity: number;
    
    constructor(productId: string, unitPrice: Money, quantity: number) {
        this.productId = productId;
        this.unitPrice = unitPrice;
        this.quantity = quantity;
    }
    
    increaseQuantity(amount: number): void {
        this.quantity += amount;
    }
    
    get total(): Money {
        return this.unitPrice.multiply(this.quantity);
    }
}

Pattern 2: Reference Entities vs. Embedded Data

When entities relate to each other, you have a choice: reference by ID or embed the related data.

Reference by ID: Order stores customerId, not the entire Customer object. Advantages: data stays consistent, entities remain independent.
Embed relevant snapshot: Order might embed a shipping address copy rather than referencing a mutable Address entity. Advantages: historical accuracy, no cascade issues.

Reference by ID

•Use when the related entity is independently managed
•Use when you always want current data
•Examples: Order references customerId
•Common for many-to-one relationships

Embed Snapshot

•Use when historical accuracy matters
•Use for value objects without identity
•Examples: Order embeds shipping address at time of purchase
•Common for auditing and historical records

Pattern 3: State-Based Entities

Many entities have explicit states that govern their behavior. An Order might be Draft, Confirmed, Paid, Shipped, Delivered, or Cancelled. A User might be Pending, Active, Suspended, or Deleted.

State-based design means:

Different states allow different operations
State transitions follow defined rules
The entity enforces its own state machine

State Machine Discipline

Common Mistakes in Entity Design

Entity design seems straightforward until you've made these mistakes a few times. Let's examine the most common pitfalls and how to avoid them.

Entity Design Anti-Patterns

•Anemic Entities — Entities that are just data bags with getters/setters, where all behavior lives elsewhere. This scatters related logic and makes the domain model unintelligible. Entities should encapsulate behavior, not just data.
•God Entities — Entities that do too much, containing every conceivable property and method. A User entity shouldn't handle authentication, authorization, profile rendering, notification preferences, and billing. Split responsibilities.
•Identity Confusion — Using mutable properties as identity (e.g., email as user ID), composite keys that are hard to manage, or auto-increment IDs treated as business identifiers. Keep identity simple, stable, and meaningful.
•Ignoring Invariants — Allowing entities to exist in invalid states (negative quantities, end date before start date, empty required fields). Entities should validate their invariants on construction and state change.
•Bi-directional References Everywhere — Making every relationship navigable in both directions. This creates tight coupling and makes it hard to reason about changes. Prefer unidirectional references.
•Confusing Entities with Database Tables — Designing entities as direct mirrors of database schema. Entities are about domain concepts, not storage. The mapping can be different.

Anemic vs Rich Entity
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// ❌ ANTI-PATTERN: Anemic Entity (just data, no behavior)
class AnemicOrder {
    public id: string;
    public items: OrderItem[] = [];
    public status: string;
    public customerId: string;
    public total: number;
    // All getters/setters, no business logic
}
 
// Someone else has to validate business rules!
function addItemToOrder(order: AnemicOrder, product: Product, qty: number) {
    // Where do we check if order is modifiable?
    // Where are the business rules?
    // This logic is scattered across the codebase
    order.items.push({ productId: product.id, qty });
    order.total = calculateTotal(order.items);
}
 
// ✅ CORRECT: Rich Entity (encapsulates behavior)
class Order {
    private readonly id: string;
    private readonly items: OrderItem[] = [];
    private status: OrderStatus = OrderStatus.Draft;
    
    constructor(id: string, customerId: string) {
        this.id = id;
        this.customerId = customerId;
    }
    
    // Behavior lives WITH the data
    addItem(product: Product, quantity: number): void {
        if (this.status !== OrderStatus.Draft) {
            throw new InvalidOperationError("Cannot modify non-draft order");
        }
        if (quantity <= 0) {
            throw new ValidationError("Quantity must be positive");
        }
        // Encapsulated logic: find existing, update or create
        const existing = this.items.find(i => i.productId === product.id);
        if (existing) {
            existing.updateQuantity(existing.quantity + quantity);
        } else {
            this.items.push(new OrderItem(product.id, product.price, quantity));
        }
    }
    
    // Calculated property, always consistent
    get total(): Money {
        return this.items.reduce(
            (sum, item) => sum.add(item.subtotal),
            Money.zero()
        );
    }
}

The Entity Litmus Test

Entity Design Principles

Based on the patterns and anti-patterns we've explored, here are guiding principles for designing effective entities:

Entity Design Principles

•Assign identity deliberately — Choose identifiers that are stable, unique, and meaningful. UUIDs work for most cases; business-meaningful IDs (like order numbers) work when the business requires them.
•Encapsulate invariants — If an order item's quantity must be positive, enforce it in the OrderItem class, not in external validation code. The entity should be impossible to corrupt from outside.
•Make invalid states unrepresentable — Use types to prevent mistakes. An EmailAddress type that validates format is better than a nullable string. An enum for status is better than a magic string.
•Favor immutability where possible — Properties that don't change (creation date, original ID) should be readonly. State changes should be explicit methods, not setter calls.
•Define clear boundaries — An entity should have a single, focused responsibility. If it's getting too large, consider splitting into multiple entities connected by references.
•Model lifecycles explicitly — If your entity has states, model them as a proper state machine with defined transitions and guard conditions.
•Use the domain language — Name your entities, properties, and methods using terms the domain experts use. This creates a ubiquitous language that bridges code and business.

Principles, Not Rules

Real-World Entity Examples

Let's examine how entities manifest across different domains. This will help you develop intuition for entity identification in unfamiliar problem spaces.

Entities Across Domains
Domain	Key Entities	Key Design Considerations
E-Commerce	Customer, Product, Order, Cart, Payment, Shipment	Order lifecycle, inventory tracking, payment state machines, address handling (entity vs VO)
Banking	Account, Transaction, Customer, Card, Loan	Transaction immutability, account balance consistency, regulatory audit trails
Healthcare	Patient, Appointment, Prescription, Provider, Facility	Patient identity across systems, appointment scheduling, medication safety invariants
Social Media	User, Post, Comment, Friendship, Notification	User identity and privacy, content moderation states, relationship modeling
Ride-Sharing	Rider, Driver, Ride, Vehicle, Location	Real-time location, ride state machine, rating systems, surge pricing
Learning Platform	Student, Course, Lesson, Enrollment, Progress	Enrollment lifecycle, progress tracking, content versioning

Notice the patterns:

Every domain has core entities that represent the fundamental "things" the business deals with
Many entities have rich lifecycles (orders, appointments, rides, enrollments)
Relationships between entities are central (customers place orders, riders request rides)
Some concepts that seem like entities might be value objects (addresses, prices, coordinates)

Summary and Next Steps

We've covered the foundational concept of entities—the building blocks of your object-oriented designs. Let's consolidate the key takeaways:

Key Takeaways

•Entities are defined by identity, not properties — Even if all properties change, an entity remains the same entity as long as its identity persists.
•Entity identification is a skill — Not every noun is an entity. Apply the identity test, lifecycle test, and domain significance test to filter accurately.
•Entities should encapsulate behavior — Rich entities that enforce their invariants are more maintainable than anemic data bags with scattered validation logic.
•Patterns help structure entities — Root/child relationships (aggregates), reference vs. embedding, and state machines are recurring patterns worth mastering.
•Avoid common pitfalls — Anemic entities, god entities, identity confusion, and ignoring invariants are traps that complicate future development.
•Domain language matters — Name entities and their operations using terms that domain experts understand. This creates shared vocabulary.

What's Next:

Page Complete

1 / 4