REQUIREMENTS & MODELING / OBJECT DESIGN BRIEF

Entity identification

Entity identification is finding the core classes of a design from the requirements.

BeginnerPhase 03 / Topic 3 of 8ResponsibilitiesCollaborationsExtensibility
01

Overview

Entity identification is finding the core classes of a design from the requirements. A reliable technique is noun-verb analysis: nouns become candidate classes or attributes, verbs become methods. Then filter: merge synonyms, drop nouns that are just attributes (color, name), and keep concepts that have identity, state, and behavior.

Good entities map to domain concepts the interviewer recognizes (Library, Book, BookCopy, Member, Loan) and separate concepts that look similar but behave differently, such as a Book (title and author) versus a BookCopy (a physical item that can be borrowed).

Casting a play

From the script, you identify the characters (entities), their traits (attributes), and what they do (methods). Extras with no lines do not need a separate actor; they are part of the scenery (attributes).

02

When to use it

  • Right after clarifying requirements.
  • When the domain has many similar-sounding concepts.
  • Refactoring a model with overloaded classes.
03

Where it shows up in interviews

Noun-verb analysis

Recognize it when: any 'design X' prompt.

  • Design a library system
  • Design a parking lot
  • Design a chess game
Type vs instance

Recognize it when: catalog items vs physical copies.

  • Design a library (Book vs BookCopy)
  • Design a car rental (Model vs Car)
04

Where it is used in real software

Domain-driven design

Entities (with identity) and value objects (defined by values) come from the ubiquitous language of domain experts.

Database modeling

Entity-relationship diagrams follow the same process for tables.

Event storming

Workshops discover entities and aggregates from domain events.

05

Key terms

Entity
Object with identity that persists over time (Member #42).
Value object
Defined by its values, no identity (Money, Address).
Attribute
A property of an entity, not a class on its own.
Type-object pattern
Separate the type (Book) from instances (BookCopy).
06

How it works, step by step

  1. 1
    Underline nouns and verbs

    From requirements and use cases.

  2. 2
    Filter nouns

    Remove synonyms, attributes, and out-of-scope items.

  3. 3
    Classify

    Entity, value object, enum, or service.

  4. 4
    Assign verbs as methods

    To the entity that owns the data.

  5. 5
    Sanity check

    Each class has a clear responsibility and a few methods.

07

Noun-verb analysis for a library

'Members borrow book copies. Each book has a title and author. A loan lasts 14 days; late returns incur a fine.'

Step 1 / 7
Noun / verbDecisionReason
MemberEntityIdentity, borrows, has loans
BookEntity (catalog)Title, author; many copies
BookCopyEntityPhysical item with barcode and status
LoanEntityLinks member and copy, due date, fine
title, authorAttributes of BookNo behavior of their own
FineValue object (Money) on LoanAmount computed from days late
borrow, returnMethodsLibrary.checkout(), Loan.close()

NOWNoun / verb: Member | Decision: Entity | Reason: Identity, borrows, has loans

Separating Book from BookCopy is the key insight; many weak designs merge them and cannot model multiple copies.

08

Implementation

type Money = { cents: number }; class Book {  constructor(readonly isbn: string, readonly title: string, readonly author: string) {}} class BookCopy {  status: "available" | "on-loan" | "lost" = "available";  constructor(readonly barcode: string, readonly book: Book) {}} class Member {  readonly loans: Loan[] = [];  constructor(readonly id: string, readonly name: string) {}} class Loan {  returnedAt?: Date;  constructor(readonly copy: BookCopy, readonly member: Member, readonly dueAt: Date) {}  fine(asOf: Date, perDay: Money): Money {    const end = this.returnedAt ?? asOf;    const daysLate = Math.max(0, Math.ceil((end.getTime() - this.dueAt.getTime()) / 86_400_000));    return { cents: daysLate * perDay.cents };  }}
09

Complexity and performance

Typical core entities4-8

For a 45-minute design.

Time~5 minutes

After requirements.

10

Trade-offs

Too few classes

God classes hold everything and violate SRP.

Too many classes

Every attribute as a class adds noise; keep simple attributes as fields or value objects.

11

Variants and related techniques

CRC cards

Class, Responsibilities, Collaborators on index cards.

Aggregates

Cluster entities that change together under a root.

12

Common mistakes

  • Merging type and instance (Book vs BookCopy).

    Fix: Ask whether there can be many physical items per catalog item.

  • Creating Manager classes for every noun.

    Fix: Put behavior on entities; use services only for cross-entity workflows.

13

Interview questions

How do you identify classes from requirements?

Use noun-verb analysis: nouns become candidate classes or attributes, verbs become methods. Then filter synonyms and attributes, classify entities vs value objects, and assign behavior to the owner of the data.

Entity vs value object?

An entity has identity and a lifecycle (Member #42 stays the same member when their name changes). A value object is defined only by its values and is usually immutable (Money, Address).

14

Practice problems

ProblemDifficultyWhat it trains
Identify entities for a car rental systemEasyModel vs Car.
Identify entities for a chess gameMediumBoard, Piece, Move, Game.