Identify core entities - Low-Level Design Guide

Overview

Step 2: identify the core entities from the agreed use cases. Walk each use case and underline nouns: cinema, screen, seat, movie, show, booking, payment, user. Keep the ones with identity, state, and behavior as classes; turn others into attributes, enums, or value objects. Separate type from instance (Seat in a screen vs ShowSeat for a particular show).

Write the entity list with one-line responsibilities before drawing relationships. Interviewers look for a clean, domain-accurate vocabulary and the key distinctions that make the design work, such as Show vs Movie and Seat vs ShowSeat.

Listing the cast before writing scenes

A playwright first lists the characters and what each wants. Scenes (interactions) come next. Extras without lines become scenery (attributes).

When to use it

Right after scoping in every LLD interview.
When a model feels tangled; re-derive entities from use cases.

Where it shows up in interviews

Noun extraction

Recognize it when: use cases written; now pick classes.

Design a movie ticket system
Design Splitwise
Design a car rental system

Where it is used in real software

DDD ubiquitous language

Entity names come from how the business talks (Show, Screening, Booking).

ER modeling

Database design follows the same entity discovery.

CRC cards

Class-Responsibility-Collaborator cards speed up entity discovery in workshops.

Key terms

Entity: Has identity and lifecycle.
Value object: Defined by values: Money, SeatType, TimeRange.
Type vs instance: Seat (physical) vs ShowSeat (seat for one show).
Service: Stateless coordinator for cross-entity use cases.

How it works, step by step

1
Extract nouns from use cases
Write them all down.
2
Merge synonyms, drop attributes
'Hall' = Screen; 'price' is an attribute.
3
Find type-vs-instance splits
Movie vs Show; Seat vs ShowSeat.
4
Classify
Entity, value object, enum, service, external interface.
5
One-line responsibility each
If you cannot state one, reconsider.

Entities for the movie ticket system

From the scoped use cases

Name	Kind	Responsibility
Movie	Entity	Title, duration, language
Cinema / Screen / Seat	Entities	Physical layout; seat type
Show	Entity	Movie on a screen at a time; owns ShowSeats
ShowSeat	Entity	Seat state for one show: available, held, booked
Hold	Entity	Temporary claim with expiry
Booking	Entity	Confirmed seats, payment reference
Money, SeatType	Value object / enum	Price and category
BookingService, PaymentGateway	Service / interface	Orchestration / external payments

NOWName: Movie | Kind: Entity | Responsibility: Title, duration, language

The ShowSeat entity is the key insight: seat availability is per show, not per physical seat.

Implementation

1type SeatType = "regular" | "premium";2type Money = Readonly<{ cents: number; currency: "INR" | "USD" }>;3 4class Movie { constructor(readonly id: string, readonly title: string, readonly minutes: number) {} }5class Seat { constructor(readonly id: string, readonly row: string, readonly type: SeatType) {} }6class Screen { constructor(readonly id: string, readonly seats: readonly Seat[]) {} }7 8class ShowSeat {9  status: "available" | "held" | "booked" = "available";10  constructor(readonly seat: Seat, readonly price: Money) {}11}12 13class Show {14  readonly seats: Map<string, ShowSeat>;15  constructor(readonly id: string, readonly movie: Movie, readonly screen: Screen, readonly startsAt: Date, price: (s: Seat) => Money) {16    this.seats = new Map(screen.seats.map((s) => [s.id, new ShowSeat(s, price(s))]));17  }18}19 20class Booking { constructor(readonly id: string, readonly showId: string, readonly userId: string, readonly seatIds: string[], readonly total: Money) {} }

Complexity and performance

Entities6-10

For a 45-minute design.

Time~5 minutes

Then relationships.

Trade-offs

Granularity

Too few entities create god classes; too many add ceremony. Aim for one clear responsibility each.

Model reality vs model behavior

Include only real-world concepts that affect the required behavior.

Variants and related techniques

Aggregates

Group Show and its ShowSeats as one consistency boundary.

Event-first discovery

Start from events (SeatHeld, BookingConfirmed) and derive entities.

Common mistakes

Storing availability on the physical Seat.
Fix: Availability belongs to ShowSeat (per show).
A single Manager class holding everything.
Fix: Entities own their data and rules; services orchestrate.

Interview questions

Why have both Seat and ShowSeat?

A physical seat exists once per screen, but its availability differs for every show. ShowSeat holds per-show state and price, while Seat holds layout information.

How do you decide whether something is a class or an attribute?

If it has identity, its own state, or behavior (a Booking), it is a class. If it only describes something else (a title, a seat row letter), it is an attribute or a value object.

Practice problems

Problem	Difficulty	What it trains
Entities for a food delivery app	Easy	Type vs instance.
Entities for an online auction	Medium	Lifecycle entities.