Identifying Actors & Entities

Master the art of identifying actors and entities - the foundation of great LLD designs!

Introduction: Why Actors & Entities Matter

Identifying actors and entities is the foundation of any good LLD design. Get this wrong, and your entire design will be flawed. Get it right, and the rest of the design flows naturally.

Visual: The Foundation

Part 1: Identifying Actors

What Are Actors?

Actors are external entities (users, systems, or processes) that interact with your system. They are outside your system boundary and use your system to achieve their goals.

Key Characteristics of Actors

External - They exist outside your system
Active - They initiate interactions
Goal-oriented - They have specific objectives
Independent - They can exist without your system

Visual: Actor Characteristics

How to Identify Actors

Ask yourself these questions:

Who uses the system?
- What roles exist?
- Who performs actions?
What external systems interact?
- APIs from other services?
- Third-party integrations?
What automated processes exist?
- Scheduled jobs?
- Background processes?
Who manages the system?
- Administrators?
- Support staff?

Example 1: Library Management System

Problem: Design a Library Management System

Step-by-Step Actor Identification:

Who uses the system?
- Member - Borrows and returns books
- Librarian - Manages books, members, and transactions
What external systems interact?
- Payment System - Processes fines and fees
- Notification System - Sends reminders and notifications
What automated processes exist?
- System - Automated processes (due date checks, fine calculations)

Actors Identified:

Member
Librarian
Payment System
Notification System
System (automated)

Visual: Library System Actors

Example 2: Restaurant Management System

Problem: Design a Restaurant Management System

Actors Identified:

Customer - Places orders, makes reservations
Waiter - Takes orders, serves food
Chef - Prepares food, updates order status
Manager - Manages menu, staff, reports
Payment Gateway - Processes payments
System - Automated processes (order tracking, notifications)

Visual: Restaurant System Actors

Common Actor Patterns

System Type	Common Actors
E-Commerce	Customer, Admin, Seller, Payment Gateway, Shipping Service
Social Media	User, Admin, Moderator, Content Moderation System
Banking	Customer, Teller, Manager, ATM, Fraud Detection System
Hotel	Guest, Receptionist, Housekeeping, Payment System
Ride-Sharing	Rider, Driver, Admin, Payment Gateway, Map Service

Common Mistakes to Avoid

Mistake 1: Confusing Actors with Entities

Wrong:

“Book” is an actor (Book doesn’t interact with the system, it’s part of it!)

Correct:

“Member” is an actor (Member interacts with the system)

Rule: Actors are external and active. Entities are internal and passive.

Mistake 2: Too Many Actors

Wrong:

Customer, Premium Customer, VIP Customer, Guest Customer (These are all the same actor with different attributes!)

Correct:

Customer (with membership type as an attribute)

Rule: Group similar roles into one actor with attributes.

Mistake 3: Missing System Actors

Wrong:

Only identifying human actors

Correct:

Also identifying automated processes and external systems

Rule: Don’t forget automated processes and external integrations!

Part 2: Identifying Entities

What Are Entities?

Entities are core objects/concepts within your system that have:

State - Data/properties
Behavior - Methods/operations
Identity - Unique identification

Key Characteristics of Entities

Internal - They exist within your system
Stateful - They hold data
Identifiable - They have unique IDs
Persistent - They may be stored in database

Visual: Entity Characteristics

How to Identify Entities

Look for nouns in the problem statement:

Core Business Objects
- What are the main concepts?
- What needs to be tracked?
Data Holders
- What information needs to be stored?
- What has properties?
Transaction Objects
- What represents transactions?
- What records events?
Configuration Objects
- What configures the system?
- What are the settings?

Example 1: Library Management System

Problem: Design a Library Management System

Step-by-Step Entity Identification:

Core Business Objects:
- Book - The main item being managed
- Member - Person who borrows books
- Library - The library itself
Transaction Objects:
- Loan - Represents a book being borrowed
- Reservation - Represents a book being reserved
- Fine - Represents a fine for overdue books
Supporting Objects:
- Author - Information about book authors
- Category - Book categories/genres

Entities Identified:

Book
Member
Library
Loan
Reservation
Fine
Author
Category

Visual: Library System Entities

classDiagram
    class Book {
        -isbn: str
        -title: str
        -author: Author
        -available: bool
    }
    class Member {
        -memberId: str
        -name: str
        -email: str
    }
    class Loan {
        -loanId: str
        -book: Book
        -member: Member
        -dueDate: Date
    }
    class Reservation {
        -reservationId: str
        -book: Book
        -member: Member
        -date: Date
    }
    class Fine {
        -fineId: str
        -loan: Loan
        -amount: float
        -paid: bool
    }
    class Author {
        -authorId: str
        -name: str
    }
    class Category {
        -categoryId: str
        -name: str
    }

Example 2: Restaurant Management System

Problem: Design a Restaurant Management System

Entities Identified:

Core Business Objects:
- Restaurant - The restaurant itself
- Table - Dining tables
- Menu - Menu items
- MenuItem - Individual menu items
- Order - Customer orders
- OrderItem - Items in an order
People Objects:
- Customer - Restaurant customers
- Staff - Restaurant staff (waiter, chef)
Transaction Objects:
- Reservation - Table reservations
- Payment - Payment transactions

Visual: Restaurant System Entities

classDiagram
    class Restaurant {
        -restaurantId: str
        -name: str
        -address: str
    }
    class Table {
        -tableId: str
        -capacity: int
        -isAvailable: bool
    }
    class MenuItem {
        -itemId: str
        -name: str
        -price: float
        -category: str
    }
    class Order {
        -orderId: str
        -table: Table
        -items: List~OrderItem~
        -status: OrderStatus
    }
    class OrderItem {
        -itemId: str
        -menuItem: MenuItem
        -quantity: int
        -specialInstructions: str
    }
    class Reservation {
        -reservationId: str
        -table: Table
        -customer: Customer
        -dateTime: DateTime
    }
    class Payment {
        -paymentId: str
        -order: Order
        -amount: float
        -method: PaymentMethod
    }

Entity Identification Techniques

Technique 1: Noun Extraction

Read the problem statement and extract nouns:

Example: “Design a Parking Lot System where drivers can park vehicles. The system should assign parking spots based on vehicle type (Car, Motorcycle, Truck). When a driver parks, they get a ticket. When they leave, they pay based on duration.”

Nouns extracted:

Parking Lot
Driver (but this is an actor!)
Vehicle
Parking Spot
Vehicle Type
Car (subtype of Vehicle)
Motorcycle (subtype of Vehicle)
Truck (subtype of Vehicle)
Ticket
Payment

Entities: ParkingLot, Vehicle, ParkingSpot, Ticket, Payment

Technique 2: Use Case Analysis

Analyze use cases to identify entities:

Use Case: “Driver parks a car”

Entities needed:

Driver (actor) - initiates action
Car (entity) - being parked
ParkingSpot (entity) - where car is parked
Ticket (entity) - proof of parking

Technique 3: Data Modeling

Think about what data needs to be stored:

What information do we need?

Parking lot details → ParkingLot entity
Spot information → ParkingSpot entity
Vehicle information → Vehicle entity
Ticket information → Ticket entity
Payment information → Payment entity

Common Entity Patterns

System Type	Common Entities
E-Commerce	Product, Order, OrderItem, Cart, Payment, User, Address
Social Media	User, Post, Comment, Like, Follow, Message
Banking	Account, Transaction, Loan, Card, Branch
Hotel	Hotel, Room, Reservation, Guest, Booking
Ride-Sharing	Rider, Driver, Ride, Vehicle, Payment, Location

Common Mistakes to Avoid

Mistake 1: Confusing Entities with Actors

Wrong:

“Driver” as an entity (Driver is an actor who uses the system)

Correct:

“Driver” as an actor, “Vehicle” as an entity

Rule: Actors are external users. Entities are internal objects.

Mistake 2: Including Implementation Details

Wrong:

Database, Cache, Queue (These are infrastructure, not business entities!)

Correct:

Focus on business entities (Book, Member, Loan)

Rule: Focus on business concepts, not technical infrastructure.

Mistake 3: Too Granular or Too Coarse

Too Granular:

BookTitle, BookAuthor, BookISBN (These are attributes of Book!)

Too Coarse:

Everything (One entity that does everything)

Correct:

Book (with title, author, ISBN as attributes)

Rule: Entities should represent meaningful business concepts with related attributes.

Part 3: Actor vs Entity - Key Differences

Visual Comparison

Comparison Table

Aspect	Actor	Entity
Location	Outside system	Inside system
Role	Uses system	Part of system
Nature	Active (initiates)	Passive (receives)
Examples	User, Admin, External System	Book, Order, Payment
Question	”Who uses it?"	"What is it?”

Decision Framework

Is it an Actor or Entity?

graph TD
    A[Is it external to the system?] -->|Yes| B[Does it initiate actions?]
    A -->|No| C[Does it have state and behavior?]
    
    B -->|Yes| D[Actor]
    B -->|No| E[External System - Still Actor]
    
    C -->|Yes| F[Entity]
    C -->|No| G[Attribute or Value Object]
    
    style D fill:#dbeafe
    style F fill:#d1fae5

Examples: Actor vs Entity

Example 1: Library System

Actor:

Member - External person who uses the system
Librarian - External person who manages the system

Entity:

Book - Internal object that represents a book
Loan - Internal object that represents a borrowing transaction

Example 2: Restaurant System

Actor:

Customer - External person who places orders
Chef - External person who prepares food

Entity:

Order - Internal object that represents a customer order
MenuItem - Internal object that represents a menu item

Part 4: Practical Exercise

Exercise: ATM System

Problem: Design an ATM System where customers can withdraw money, check balance, and transfer funds.

Your Task: Identify actors and entities.

Solution:

Actors:

Customer - Uses ATM to perform transactions
Bank - External system that validates transactions
System - Automated processes (transaction logging, fraud detection)

Entities:

ATM - The ATM machine itself
Account - Customer’s bank account
Card - ATM card used for authentication
Transaction - Represents a transaction (withdrawal, transfer, etc.)
Balance - Account balance information

Visual: ATM System Actors & Entities

Summary: Identifying Actors & Entities

Key Takeaways

Actors are external - they use the system
Entities are internal - they are part of the system
Actors are active - they initiate actions
Entities are passive - they receive actions
Use noun extraction - Extract nouns from problem statement
Think about use cases - What entities are needed?
Avoid common mistakes - Don’t confuse actors with entities

Visual Summary

Checklist

Use this checklist when identifying actors and entities:

Actors:

Who uses the system?
What external systems interact?
What automated processes exist?
Are they external to the system?
Do they initiate actions?

Entities:

What are the core business objects?
What data needs to be stored?
What represents transactions?
Are they internal to the system?
Do they have state and behavior?

Next Steps

Now that you’ve mastered identifying actors and entities, let’s learn how to assign responsibilities:

Next: Assign Responsibilities →

This next guide will teach you how to systematically assign responsibilities to each entity, following SOLID principles and best practices!