Low-Level DesignEntities, Attributes, and Behaviors

Entities, Attributes, and Behaviors

LevelBeginner

Duration60 mins

TopicEntities, Attributes, and Behaviors

4 / 4

Distinguishing Essential from Incidental Properties

The Art of Knowing What Matters

Throughout this module, we've explored entities as identifiable things, attributes as their descriptive properties, and behaviors as their capabilities. But there's a deeper skill that separates adequate models from exceptional ones: knowing what truly matters.

Every entity has properties that are essential—fundamental to its identity and purpose—and properties that are incidental—present in specific contexts but not definitional. The ability to distinguish between these shapes everything from how you design classes to how you evolve systems over time.

What You Will Learn

By the end of this page, you will understand the philosophical and practical distinction between essential and incidental properties, develop frameworks for making this distinction in real-world domains, and learn how to apply this thinking to create domain models that are robust, extensible, and true to the problem they represent.

Essential vs. Incidental — The Philosophy

This distinction has roots stretching back to Aristotle, who differentiated between a thing's essence (what makes it what it is) and its accidents (properties it happens to have but could be otherwise).

In software terms:

Essential properties are those without which the entity would not be that type of entity. They define the entity's identity and fundamental nature.
Incidental properties are those the entity happens to have in particular contexts but could differ without changing the entity's fundamental nature.

Let's make this concrete with examples:

Essential vs. Incidental Properties
Entity	Essential Properties	Incidental Properties
User	Identity (ID), authentication credentials, account status	Profile picture, bio, preferred language, theme preference
Order	Identity, customer, items (at least one), total, status	Gift message, delivery instructions, marketing attribution
Book	Title, author(s), ISBN	Cover image URL, page count, publisher, reviews
Payment	Amount, currency, payer, payee, status	Memo, payment method details, IP address of request
Course	Title, syllabus, instructor(s)	Featured image, promotional video, enrollment count

The test of essential properties:

Ask yourself: If this property were missing or different, would this still be the same type of thing?

A User without credentials can't authenticate—are they really a User or just a Person record?
An Order without items isn't an order—it's an empty shopping cart or nothing at all.
A Book without a title could exist (rare historical manuscripts) but barely qualifies as a cataloged book.

Essential properties define the minimum viable entity—the core that must exist for the entity to be coherent.

Context Shifts Essentiality

What's essential depends on context. For a library catalog system, a book's ISBN and publisher are essential—they identify the canonical edition. For a personal reading list app, only title might be essential; users might add books before knowing publisher details. Model for YOUR domain, not some abstract ideal.

Why the Distinction Matters

Getting this distinction wrong has cascading consequences throughout your system:

Consequences of Incorrect Classification

•Treating incidental as essential → Rigid, over-constrained systems — Requiring a profile picture on registration blocks users who don't have one ready. Requiring full address before browsing frustrates exploration. Users abandon.
•Treating essential as incidental → Invalid states proliferate — If Order.customerId is optional, who placed this order? If User.email is nullable, how do they log in? Now you have data integrity issues everywhere.
•Database schema impacts — Essential properties often become NOT NULL columns. Incidental properties become nullable. Getting this wrong forces migrations later.
•API design impacts — Essential properties are required on creation endpoints. Incidental are optional. Wrong classification = poor developer experience.
•Validation logic — Essential validation runs always. Incidental validation runs only when present. Misclassification = scattered, inconsistent validation.
•Testing burden — Each essential property must be provided in every test. Over-classifying increases test setup; under-classifying hides bugs.

Classification Impact on API Design
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
// Classification directly shapes your API contract
 
// Essential properties = required in creation
interface CreateOrderRequest {
    customerId: string;         // Essential: whose order?
    items: OrderItemInput[];    // Essential: what are they buying?
    shippingAddressId: string;  // Essential: where does it go?
    billingAddressId?: string;  // Incidental: defaults to shipping if not specified
    giftMessage?: string;       // Incidental: entirely optional
    couponCode?: string;        // Incidental: optional discount
}
 
// The Order entity reflects this
class Order {
    // Essential — provided at construction, never null
    private readonly id: OrderId;
    private readonly customerId: CustomerId;
    private readonly shippingAddress: Address;
    private readonly createdAt: Date;
    private items: OrderItem[];           // May change but never empty
    private status: OrderStatus;          // Always has a state
    
    // Incidental — may be null, set separately, have defaults
    private billingAddress?: Address;     // Defaults to shipping
    private giftMessage?: string;         // Completely optional
    private couponId?: CouponId;          // Applied or not
    private notes?: string;               // Added by support later
    
    constructor(data: CreateOrderData) {
        // Essential properties: validated and required
        if (!data.customerId) throw new ValidationError("Customer required");
        if (!data.items?.length) throw new ValidationError("At least one item required");
        if (!data.shippingAddress) throw new ValidationError("Shipping address required");
        
        this.id = OrderId.generate();
        this.customerId = data.customerId;
        this.items = data.items;
        this.shippingAddress = data.shippingAddress;
        this.status = OrderStatus.Draft;
        this.createdAt = new Date();
        
        // Incidental properties: use defaults or leave undefined
        this.billingAddress = data.billingAddress;  // undefined is OK
        this.giftMessage = data.giftMessage;        // undefined is OK
    }
}

The Constructor as Essential Enforcer

Your constructor signature IS your statement of essential properties. If it's in the constructor with no default, it's essential. If it can be set afterward or has a default, it's incidental. Make this intentional, not accidental.

Frameworks for Making the Distinction

Deciding essential vs. incidental isn't always obvious. Here are decision frameworks to guide your classification:

Framework 1: The Existence Test

Can this entity exist without this property?

An Order without items cannot exist—items are essential
A User without a bio can exist—bio is incidental
A Payment without an amount cannot exist—amount is essential

This is the most fundamental test: if the entity is incoherent or meaningless without the property, it's essential.

Framework 2: The Core Use Case Test

Is this property required for the entity to fulfill its primary purpose?

A Book's purpose is to be read/cataloged → title and content identifiers are essential
A Book's purpose is NOT marketing → featured image is incidental
An Order's purpose is to capture and fulfill a purchase → items and destination are essential
An Order's purpose is NOT to facilitate gift-giving → gift message is incidental

Essential properties are what the entity needs to DO ITS JOB.

Framework 3: The Universality Test

Does every instance of this entity have this property?

Every Order has a customer (even if it's a guest session) → essential
Not every Order has a coupon code → incidental
Every User has a creation timestamp → essential
Not every User has completed their profile → incidental

If something is only present sometimes, it's likely incidental.

Framework 4: The Stability Test

Is this property stable across the entity's lifecycle?

Order.customerId doesn't change → more likely essential
Order.shippingAddress might change before confirmation → still essential (must always have one)
Order.trackingNumber is only set after shipping → incidental

Essential properties tend to be stable or always-present; incidental properties come and go.

Summary: Essential Property Indicators

•Required for entity to exist meaningfully
•Needed for core use cases to function
•Present in every instance of the entity
•Stable across entity lifecycle (always has a value)
•Domain expert considers it definitional

Summary: Incidental Property Indicators

•Entity is valid without it
•Supports secondary or edge-case use cases
•Only present in some instances
•Added/changed after entity creation
•Domain expert considers it supplementary or optional

The Gray Zone — Contextual Essentiality

Real-world domains aren't black and white. Some properties are essential in certain contexts and incidental in others. Recognizing this nuance prevents both over-rigid and over-loose designs.

Example: User.email in Different Systems

In an email-based login system: Essential—no email, no login, no user
In a social login system (Google/Apple): Incidental—users exist via OAuth; email is optional enrichment
In an enterprise SSO system: Irrelevant—corporate ID is identity, email is just a contact method

The 'same' entity can have different essential properties based on the bounded context it lives in. This is a core insight of Domain-Driven Design: models are context-specific, not universal.

Context-Dependent Essentiality
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
56
57
58
59
60
61
62
63
64
65
// Same "User" concept, different bounded contexts
 
// ==========================================
// Authentication Context — email is essential
// ==========================================
class AuthUser {
    private readonly id: UserId;
    private readonly email: EmailAddress;     // ESSENTIAL: login credential
    private passwordHash: PasswordHash;       // ESSENTIAL: authentication
    private mfaEnabled: boolean;
    
    constructor(id: UserId, email: EmailAddress, passwordHash: PasswordHash) {
        // All essential properties required
        this.id = id;
        this.email = email;
        this.passwordHash = passwordHash;
        this.mfaEnabled = false;
    }
    
    authenticate(password: string): boolean {
        return this.passwordHash.matches(password);
    }
}
 
// ==========================================
// Profile Context — email is incidental
// ==========================================
class UserProfile {
    private readonly userId: UserId;          // ESSENTIAL: links to auth
    private displayName: string;              // ESSENTIAL for display
    private avatarUrl?: string;               // Incidental
    private bio?: string;                     // Incidental
    private contactEmail?: EmailAddress;      // INCIDENTAL: optional contact info
    private socialLinks: SocialLink[];        // Incidental
    
    constructor(userId: UserId, displayName: string) {
        this.userId = userId;
        this.displayName = displayName;
        this.socialLinks = [];
    }
    
    updateContactEmail(email?: EmailAddress): void {
        this.contactEmail = email;  // Can be set to null
    }
}
 
// ==========================================
// E-Commerce Context — email for receipts
// ==========================================
class Customer {
    private readonly id: CustomerId;
    private readonly accountId?: UserId;      // Incidental: guest checkout allowed
    private email: EmailAddress;              // ESSENTIAL: receipts, tracking
    private shippingAddresses: Address[];
    
    constructor(id: CustomerId, email: EmailAddress, accountId?: UserId) {
        this.id = id;
        this.email = email;
        this.accountId = accountId;  // undefined for guest checkout
        this.shippingAddresses = [];
    }
}
 
// The lesson: what's essential depends on the bounded context.
// Don't try to create one universal User class that handles all cases.

Avoid the Universal Model Trap

Trying to create one model that works for all contexts forces you to make everything optional (to handle contexts where it's incidental) or required (breaking contexts where it's incidental). Instead, accept that different bounded contexts may have different entity definitions even for 'the same' concept.

Applying the Distinction in Practice

Let's walk through a realistic design process that applies essential/incidental classification:

Scenario: Designing a Job Posting Entity

Requirements: "Companies post jobs. Jobs have titles, descriptions, locations, salary ranges, required skills, and application deadlines. Some jobs are remote, some require relocation. Jobs can be featured or urgent. Companies can track which jobs get the most views."

Step 1: Extract all potential properties

Title, description, location, salary range, required skills, application deadline, company, is remote, requires relocation, is featured, is urgent, view count, created date...

Step 2: Apply the frameworks

Property Classification Analysis
Property	Existence?	Core Purpose?	Universal?	Classification
Title	Cannot post without title	Identifies job	All jobs have one	Essential
Company	Must know who's hiring	Core to job	All jobs have one	Essential
Description	Could have minimal jobs	Secondary (title suffices for basic)	Most have one	Essential (borderline)
Location	Remote jobs may not need	Filtering essential	Most have one	Essential (with 'Remote' option)
Salary range	Many jobs don't list	Filtering helpful, not core	Maybe 50% have it	Incidental
Required skills	Could be in description	Filtering helpful	Not all specify	Incidental
Deadline	Not all jobs expire	Time-sensitive use case	Many don't have	Incidental
Is Remote	Needed for remote jobs	Filtering essential	All have explicit or implied value	Essential (boolean flag)
Is Featured	Display enhancement	Marketing, not core	Few are featured	Incidental
View Count	Analytics	Not job function	Runtime computed	Incidental (or derived)

JobPosting Entity Design
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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
class JobPosting {
    // === ESSENTIAL PROPERTIES ===
    private readonly id: JobPostingId;
    private readonly companyId: CompanyId;
    private title: string;
    private description: string;
    private readonly createdAt: Date;
    private status: JobStatus;
    private location: JobLocation;  // Includes remote option
    
    // === INCIDENTAL PROPERTIES ===
    private salaryRange?: SalaryRange;
    private requiredSkills: Skill[];           // Empty array if none specified
    private applicationDeadline?: Date;
    private isFeatured: boolean;               // Default false
    private isUrgent: boolean;                 // Default false
    private externalApplyUrl?: string;
    private viewCount: number;                 // Analytics, starts at 0
    
    constructor(
        id: JobPostingId,
        companyId: CompanyId,
        title: string,
        description: string,
        location: JobLocation
    ) {
        // Validate essential properties
        if (!title?.trim()) {
            throw new ValidationError("Job title is required");
        }
        if (!description?.trim()) {
            throw new ValidationError("Job description is required");
        }
        
        this.id = id;
        this.companyId = companyId;
        this.title = title.trim();
        this.description = description.trim();
        this.location = location;
        this.createdAt = new Date();
        this.status = JobStatus.Draft;
        
        // Incidental properties get sensible defaults
        this.requiredSkills = [];
        this.isFeatured = false;
        this.isUrgent = false;
        this.viewCount = 0;
    }
    
    // Essential properties may have restricted updates
    updateTitle(title: string): void {
        if (!title?.trim()) {
            throw new ValidationError("Job title cannot be empty");
        }
        this.ensureDraft("Cannot update title of published job");
        this.title = title.trim();
    }
    
    // Incidental properties have more flexible updates
    setSalaryRange(range: SalaryRange | undefined): void {
        this.salaryRange = range;  // Can set or clear
    }
    
    addRequiredSkill(skill: Skill): void {
        if (!this.requiredSkills.some(s => s.equals(skill))) {
            this.requiredSkills.push(skill);
        }
    }
    
    setFeatured(featured: boolean): void {
        this.isFeatured = featured;
    }
    
    private ensureDraft(message: string): void {
        if (this.status !== JobStatus.Draft) {
            throw new InvalidOperationError(message);
        }
    }
}
 
// Location handles the remote/physical distinction
class JobLocation {
    private constructor(
        private readonly type: "remote" | "onsite" | "hybrid",
        private readonly city?: string,
        private readonly country?: string
    ) {}
    
    static remote(): JobLocation {
        return new JobLocation("remote");
    }
    
    static onsite(city: string, country: string): JobLocation {
        return new JobLocation("onsite", city, country);
    }
    
    static hybrid(city: string, country: string): JobLocation {
        return new JobLocation("hybrid", city, country);
    }
    
    get isRemote(): boolean {
        return this.type === "remote" || this.type === "hybrid";
    }
}

Evolution Over Time

Essential and incidental aren't fixed forever. As your domain evolves, properties may shift classification. Being prepared for this change is key to maintainable systems.

Pattern 1: Incidental Becomes Essential

Your e-commerce platform initially allowed guest checkout, making userId incidental on Order. But new requirements demand order history, loyalty points, and personalization—now userId is essential.

Strategy: Migrate existing orders to link to auto-created accounts or a 'guest' placeholder. Update constraints and validation. This is usually the easier direction.

Pattern 2: Essential Becomes Incidental

Your system required phone number for all users (essential). But users hate providing it, and SMS verification is no longer your primary flow—now phone is incidental.

Strategy: Relax constraints. Make field nullable in database. Update constructor to accept undefined. Harder than the reverse because existing code may assume presence.

Pattern 3: New Property Added

A new feature requires tracking which marketing campaign brought each order. Is campaignId essential or incidental?

Strategy: For new properties, start incidental unless clearly essential. It's easier to tighten later than to loosen. Default to optional and see if every instance naturally has a value.

Schema Evolution Strategy

Database migration difficulty is a reason to be conservative about marking things essential. Making a nullable column NOT NULL requires backfilling data. Making a NOT NULL column nullable is trivial. When uncertain, start incidental.

Evolution Guidelines

•Review classification periodically — As requirements evolve, revisit what's essential. Product growth often promotes incidental to essential.
•Version your models if needed — In API design, major changes to essentiality may warrant a new version.
•Migrate data carefully — When promoting to essential, ensure all existing instances have valid values before enforcing the constraint.
•Communicate changes — If an API changes a field from optional to required, that's a breaking change. Handle it explicitly.

Integration with Behaviors

Essential and incidental classification doesn't just apply to attributes—it extends to behaviors as well. Some behaviors are fundamental to what the entity IS; others are situational or optional.

Essential Behaviors

•Core state transitions (Order.confirm, User.suspend)
•Invariant enforcement (no negative balance, no empty orders)
•Identity operations (equals, hashCode)
•Primary business functions (Account.withdraw, Product.updatePrice)

Incidental Behaviors

•Analytics updates (Order.trackView, Product.recordClick)
•Notification triggers (User.notifyOnUpdate)
•Convenience methods (User.formatFullName)
•Integration operations (Order.syncToExternalSystem)

Why distinguish behavior essentiality?

Testing priority — Essential behaviors need comprehensive testing. Incidental behaviors can have lighter coverage.
Refactoring safety — Changing incidental behaviors is lower risk. Essential behaviors need careful consideration.
Cohesion decisions — If incidental behaviors proliferate, consider extracting them to services.
Documentation focus — Essential behaviors define the entity's contract. Document them thoroughly.

Behaviors Can Shift Too

Just like attributes, behaviors can shift between essential and incidental. Email notification was once essential for Order.confirm(); now it's a side effect handled by event subscribers. As systems mature, behaviors often migrate out of entities into services, making entities cleaner and more focused.

Summary — Bringing It All Together

This module has given you the complete toolkit for modeling entities:

Entities are identifiable things with continuity and meaning
Attributes describe entities through properties of various categories
Behaviors define what entities can do through encapsulated methods
Essential vs. Incidental distinguishes what's fundamental from what's supplementary

Together, these concepts enable you to create domain models that are:

True to the domain — Capturing what matters to the business
Complete yet focused — Having everything needed, nothing extraneous
Robust — Enforcing invariants and protecting validity
Evolvable — Clear enough to modify as requirements change

Module Key Takeaways

•Entities are defined by identity, not attributes — Identity persists through change. Model entities around their identity, not their current properties.
•Attributes describe; behaviors act — Rich entities have both meaningful data AND encapsulated operations. Avoid anemic models.
•Essential properties are required; incidental are optional — This classification shapes constructors, APIs, database schemas, and validation logic.
•Context determines essentiality — What's essential in one bounded context may be incidental in another. Accept this; don't force universal models.
•Classification evolves — Properties and behaviors shift between essential and incidental as requirements change. Design for evolution.
•Use frameworks, not intuition — Apply existence, core purpose, universality, and stability tests to classify properties systematically.

What's Next:

With entities, attributes, and behaviors mastered, you're ready to explore how entities relate to each other. The next module covers Relationships Between Objects—association, dependency, aggregation, and composition—the connections that turn individual entities into a coherent domain model.

Module Complete

You now have a comprehensive understanding of entities, attributes, behaviors, and the essential/incidental distinction. You can model domain concepts as rich, cohesive entities that accurately represent business reality. Next, we'll explore how these entities connect through relationships.

4 / 4

Loading learning content...

Low-Level DesignEntities, Attributes, and Behaviors

Entities, Attributes, and Behaviors

LevelBeginner

Duration60 mins

TopicEntities, Attributes, and Behaviors

4 / 4

Distinguishing Essential from Incidental Properties

The Art of Knowing What Matters

What You Will Learn

Essential vs. Incidental — The Philosophy

In software terms:

Essential properties are those without which the entity would not be that type of entity. They define the entity's identity and fundamental nature.
Incidental properties are those the entity happens to have in particular contexts but could differ without changing the entity's fundamental nature.

Let's make this concrete with examples:

Essential vs. Incidental Properties
Entity	Essential Properties	Incidental Properties
User	Identity (ID), authentication credentials, account status	Profile picture, bio, preferred language, theme preference
Order	Identity, customer, items (at least one), total, status	Gift message, delivery instructions, marketing attribution
Book	Title, author(s), ISBN	Cover image URL, page count, publisher, reviews
Payment	Amount, currency, payer, payee, status	Memo, payment method details, IP address of request
Course	Title, syllabus, instructor(s)	Featured image, promotional video, enrollment count

The test of essential properties:

Ask yourself: If this property were missing or different, would this still be the same type of thing?

A User without credentials can't authenticate—are they really a User or just a Person record?
An Order without items isn't an order—it's an empty shopping cart or nothing at all.
A Book without a title could exist (rare historical manuscripts) but barely qualifies as a cataloged book.

Essential properties define the minimum viable entity—the core that must exist for the entity to be coherent.

Context Shifts Essentiality

Why the Distinction Matters

Getting this distinction wrong has cascading consequences throughout your system:

Consequences of Incorrect Classification

•Treating incidental as essential → Rigid, over-constrained systems — Requiring a profile picture on registration blocks users who don't have one ready. Requiring full address before browsing frustrates exploration. Users abandon.
•Treating essential as incidental → Invalid states proliferate — If Order.customerId is optional, who placed this order? If User.email is nullable, how do they log in? Now you have data integrity issues everywhere.
•Database schema impacts — Essential properties often become NOT NULL columns. Incidental properties become nullable. Getting this wrong forces migrations later.
•API design impacts — Essential properties are required on creation endpoints. Incidental are optional. Wrong classification = poor developer experience.
•Validation logic — Essential validation runs always. Incidental validation runs only when present. Misclassification = scattered, inconsistent validation.
•Testing burden — Each essential property must be provided in every test. Over-classifying increases test setup; under-classifying hides bugs.

Classification Impact on API Design
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
// Classification directly shapes your API contract
 
// Essential properties = required in creation
interface CreateOrderRequest {
    customerId: string;         // Essential: whose order?
    items: OrderItemInput[];    // Essential: what are they buying?
    shippingAddressId: string;  // Essential: where does it go?
    billingAddressId?: string;  // Incidental: defaults to shipping if not specified
    giftMessage?: string;       // Incidental: entirely optional
    couponCode?: string;        // Incidental: optional discount
}
 
// The Order entity reflects this
class Order {
    // Essential — provided at construction, never null
    private readonly id: OrderId;
    private readonly customerId: CustomerId;
    private readonly shippingAddress: Address;
    private readonly createdAt: Date;
    private items: OrderItem[];           // May change but never empty
    private status: OrderStatus;          // Always has a state
    
    // Incidental — may be null, set separately, have defaults
    private billingAddress?: Address;     // Defaults to shipping
    private giftMessage?: string;         // Completely optional
    private couponId?: CouponId;          // Applied or not
    private notes?: string;               // Added by support later
    
    constructor(data: CreateOrderData) {
        // Essential properties: validated and required
        if (!data.customerId) throw new ValidationError("Customer required");
        if (!data.items?.length) throw new ValidationError("At least one item required");
        if (!data.shippingAddress) throw new ValidationError("Shipping address required");
        
        this.id = OrderId.generate();
        this.customerId = data.customerId;
        this.items = data.items;
        this.shippingAddress = data.shippingAddress;
        this.status = OrderStatus.Draft;
        this.createdAt = new Date();
        
        // Incidental properties: use defaults or leave undefined
        this.billingAddress = data.billingAddress;  // undefined is OK
        this.giftMessage = data.giftMessage;        // undefined is OK
    }
}

The Constructor as Essential Enforcer

Frameworks for Making the Distinction

Deciding essential vs. incidental isn't always obvious. Here are decision frameworks to guide your classification:

Framework 1: The Existence Test

Can this entity exist without this property?

An Order without items cannot exist—items are essential
A User without a bio can exist—bio is incidental
A Payment without an amount cannot exist—amount is essential

This is the most fundamental test: if the entity is incoherent or meaningless without the property, it's essential.

Framework 2: The Core Use Case Test

Is this property required for the entity to fulfill its primary purpose?

A Book's purpose is to be read/cataloged → title and content identifiers are essential
A Book's purpose is NOT marketing → featured image is incidental
An Order's purpose is to capture and fulfill a purchase → items and destination are essential
An Order's purpose is NOT to facilitate gift-giving → gift message is incidental

Essential properties are what the entity needs to DO ITS JOB.

Framework 3: The Universality Test

Does every instance of this entity have this property?

Every Order has a customer (even if it's a guest session) → essential
Not every Order has a coupon code → incidental
Every User has a creation timestamp → essential
Not every User has completed their profile → incidental

If something is only present sometimes, it's likely incidental.

Framework 4: The Stability Test

Is this property stable across the entity's lifecycle?

Order.customerId doesn't change → more likely essential
Order.shippingAddress might change before confirmation → still essential (must always have one)
Order.trackingNumber is only set after shipping → incidental

Essential properties tend to be stable or always-present; incidental properties come and go.

Summary: Essential Property Indicators

•Required for entity to exist meaningfully
•Needed for core use cases to function
•Present in every instance of the entity
•Stable across entity lifecycle (always has a value)
•Domain expert considers it definitional

Summary: Incidental Property Indicators

•Entity is valid without it
•Supports secondary or edge-case use cases
•Only present in some instances
•Added/changed after entity creation
•Domain expert considers it supplementary or optional

The Gray Zone — Contextual Essentiality

Real-world domains aren't black and white. Some properties are essential in certain contexts and incidental in others. Recognizing this nuance prevents both over-rigid and over-loose designs.

Example: User.email in Different Systems

In an email-based login system: Essential—no email, no login, no user
In a social login system (Google/Apple): Incidental—users exist via OAuth; email is optional enrichment
In an enterprise SSO system: Irrelevant—corporate ID is identity, email is just a contact method

The 'same' entity can have different essential properties based on the bounded context it lives in. This is a core insight of Domain-Driven Design: models are context-specific, not universal.

Context-Dependent Essentiality
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
56
57
58
59
60
61
62
63
64
65
// Same "User" concept, different bounded contexts
 
// ==========================================
// Authentication Context — email is essential
// ==========================================
class AuthUser {
    private readonly id: UserId;
    private readonly email: EmailAddress;     // ESSENTIAL: login credential
    private passwordHash: PasswordHash;       // ESSENTIAL: authentication
    private mfaEnabled: boolean;
    
    constructor(id: UserId, email: EmailAddress, passwordHash: PasswordHash) {
        // All essential properties required
        this.id = id;
        this.email = email;
        this.passwordHash = passwordHash;
        this.mfaEnabled = false;
    }
    
    authenticate(password: string): boolean {
        return this.passwordHash.matches(password);
    }
}
 
// ==========================================
// Profile Context — email is incidental
// ==========================================
class UserProfile {
    private readonly userId: UserId;          // ESSENTIAL: links to auth
    private displayName: string;              // ESSENTIAL for display
    private avatarUrl?: string;               // Incidental
    private bio?: string;                     // Incidental
    private contactEmail?: EmailAddress;      // INCIDENTAL: optional contact info
    private socialLinks: SocialLink[];        // Incidental
    
    constructor(userId: UserId, displayName: string) {
        this.userId = userId;
        this.displayName = displayName;
        this.socialLinks = [];
    }
    
    updateContactEmail(email?: EmailAddress): void {
        this.contactEmail = email;  // Can be set to null
    }
}
 
// ==========================================
// E-Commerce Context — email for receipts
// ==========================================
class Customer {
    private readonly id: CustomerId;
    private readonly accountId?: UserId;      // Incidental: guest checkout allowed
    private email: EmailAddress;              // ESSENTIAL: receipts, tracking
    private shippingAddresses: Address[];
    
    constructor(id: CustomerId, email: EmailAddress, accountId?: UserId) {
        this.id = id;
        this.email = email;
        this.accountId = accountId;  // undefined for guest checkout
        this.shippingAddresses = [];
    }
}
 
// The lesson: what's essential depends on the bounded context.
// Don't try to create one universal User class that handles all cases.

Avoid the Universal Model Trap

Applying the Distinction in Practice

Let's walk through a realistic design process that applies essential/incidental classification:

Scenario: Designing a Job Posting Entity

Step 1: Extract all potential properties

Title, description, location, salary range, required skills, application deadline, company, is remote, requires relocation, is featured, is urgent, view count, created date...

Step 2: Apply the frameworks

Property Classification Analysis
Property	Existence?	Core Purpose?	Universal?	Classification
Title	Cannot post without title	Identifies job	All jobs have one	Essential
Company	Must know who's hiring	Core to job	All jobs have one	Essential
Description	Could have minimal jobs	Secondary (title suffices for basic)	Most have one	Essential (borderline)
Location	Remote jobs may not need	Filtering essential	Most have one	Essential (with 'Remote' option)
Salary range	Many jobs don't list	Filtering helpful, not core	Maybe 50% have it	Incidental
Required skills	Could be in description	Filtering helpful	Not all specify	Incidental
Deadline	Not all jobs expire	Time-sensitive use case	Many don't have	Incidental
Is Remote	Needed for remote jobs	Filtering essential	All have explicit or implied value	Essential (boolean flag)
Is Featured	Display enhancement	Marketing, not core	Few are featured	Incidental
View Count	Analytics	Not job function	Runtime computed	Incidental (or derived)

JobPosting Entity Design
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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
class JobPosting {
    // === ESSENTIAL PROPERTIES ===
    private readonly id: JobPostingId;
    private readonly companyId: CompanyId;
    private title: string;
    private description: string;
    private readonly createdAt: Date;
    private status: JobStatus;
    private location: JobLocation;  // Includes remote option
    
    // === INCIDENTAL PROPERTIES ===
    private salaryRange?: SalaryRange;
    private requiredSkills: Skill[];           // Empty array if none specified
    private applicationDeadline?: Date;
    private isFeatured: boolean;               // Default false
    private isUrgent: boolean;                 // Default false
    private externalApplyUrl?: string;
    private viewCount: number;                 // Analytics, starts at 0
    
    constructor(
        id: JobPostingId,
        companyId: CompanyId,
        title: string,
        description: string,
        location: JobLocation
    ) {
        // Validate essential properties
        if (!title?.trim()) {
            throw new ValidationError("Job title is required");
        }
        if (!description?.trim()) {
            throw new ValidationError("Job description is required");
        }
        
        this.id = id;
        this.companyId = companyId;
        this.title = title.trim();
        this.description = description.trim();
        this.location = location;
        this.createdAt = new Date();
        this.status = JobStatus.Draft;
        
        // Incidental properties get sensible defaults
        this.requiredSkills = [];
        this.isFeatured = false;
        this.isUrgent = false;
        this.viewCount = 0;
    }
    
    // Essential properties may have restricted updates
    updateTitle(title: string): void {
        if (!title?.trim()) {
            throw new ValidationError("Job title cannot be empty");
        }
        this.ensureDraft("Cannot update title of published job");
        this.title = title.trim();
    }
    
    // Incidental properties have more flexible updates
    setSalaryRange(range: SalaryRange | undefined): void {
        this.salaryRange = range;  // Can set or clear
    }
    
    addRequiredSkill(skill: Skill): void {
        if (!this.requiredSkills.some(s => s.equals(skill))) {
            this.requiredSkills.push(skill);
        }
    }
    
    setFeatured(featured: boolean): void {
        this.isFeatured = featured;
    }
    
    private ensureDraft(message: string): void {
        if (this.status !== JobStatus.Draft) {
            throw new InvalidOperationError(message);
        }
    }
}
 
// Location handles the remote/physical distinction
class JobLocation {
    private constructor(
        private readonly type: "remote" | "onsite" | "hybrid",
        private readonly city?: string,
        private readonly country?: string
    ) {}
    
    static remote(): JobLocation {
        return new JobLocation("remote");
    }
    
    static onsite(city: string, country: string): JobLocation {
        return new JobLocation("onsite", city, country);
    }
    
    static hybrid(city: string, country: string): JobLocation {
        return new JobLocation("hybrid", city, country);
    }
    
    get isRemote(): boolean {
        return this.type === "remote" || this.type === "hybrid";
    }
}

Evolution Over Time

Essential and incidental aren't fixed forever. As your domain evolves, properties may shift classification. Being prepared for this change is key to maintainable systems.

Pattern 1: Incidental Becomes Essential

Strategy: Migrate existing orders to link to auto-created accounts or a 'guest' placeholder. Update constraints and validation. This is usually the easier direction.

Pattern 2: Essential Becomes Incidental

Your system required phone number for all users (essential). But users hate providing it, and SMS verification is no longer your primary flow—now phone is incidental.

Strategy: Relax constraints. Make field nullable in database. Update constructor to accept undefined. Harder than the reverse because existing code may assume presence.

Pattern 3: New Property Added

A new feature requires tracking which marketing campaign brought each order. Is campaignId essential or incidental?

Strategy: For new properties, start incidental unless clearly essential. It's easier to tighten later than to loosen. Default to optional and see if every instance naturally has a value.

Schema Evolution Strategy

Evolution Guidelines

•Review classification periodically — As requirements evolve, revisit what's essential. Product growth often promotes incidental to essential.
•Version your models if needed — In API design, major changes to essentiality may warrant a new version.
•Migrate data carefully — When promoting to essential, ensure all existing instances have valid values before enforcing the constraint.
•Communicate changes — If an API changes a field from optional to required, that's a breaking change. Handle it explicitly.

Integration with Behaviors

Essential and incidental classification doesn't just apply to attributes—it extends to behaviors as well. Some behaviors are fundamental to what the entity IS; others are situational or optional.

Essential Behaviors

•Core state transitions (Order.confirm, User.suspend)
•Invariant enforcement (no negative balance, no empty orders)
•Identity operations (equals, hashCode)
•Primary business functions (Account.withdraw, Product.updatePrice)

Incidental Behaviors

•Analytics updates (Order.trackView, Product.recordClick)
•Notification triggers (User.notifyOnUpdate)
•Convenience methods (User.formatFullName)
•Integration operations (Order.syncToExternalSystem)

Why distinguish behavior essentiality?

Testing priority — Essential behaviors need comprehensive testing. Incidental behaviors can have lighter coverage.
Refactoring safety — Changing incidental behaviors is lower risk. Essential behaviors need careful consideration.
Cohesion decisions — If incidental behaviors proliferate, consider extracting them to services.
Documentation focus — Essential behaviors define the entity's contract. Document them thoroughly.

Behaviors Can Shift Too

Summary — Bringing It All Together

This module has given you the complete toolkit for modeling entities:

Entities are identifiable things with continuity and meaning
Attributes describe entities through properties of various categories
Behaviors define what entities can do through encapsulated methods
Essential vs. Incidental distinguishes what's fundamental from what's supplementary

Together, these concepts enable you to create domain models that are:

True to the domain — Capturing what matters to the business
Complete yet focused — Having everything needed, nothing extraneous
Robust — Enforcing invariants and protecting validity
Evolvable — Clear enough to modify as requirements change

Module Key Takeaways

•Entities are defined by identity, not attributes — Identity persists through change. Model entities around their identity, not their current properties.
•Attributes describe; behaviors act — Rich entities have both meaningful data AND encapsulated operations. Avoid anemic models.
•Essential properties are required; incidental are optional — This classification shapes constructors, APIs, database schemas, and validation logic.
•Context determines essentiality — What's essential in one bounded context may be incidental in another. Accept this; don't force universal models.
•Classification evolves — Properties and behaviors shift between essential and incidental as requirements change. Design for evolution.
•Use frameworks, not intuition — Apply existence, core purpose, universality, and stability tests to classify properties systematically.

What's Next:

Module Complete

4 / 4