After learning core object-oriented concepts like encapsulation, inheritance, polymorphism, interfaces, dependency injection, factories, and system layering, one critical skill still remains:

How do we convert a problem statement into actual classes and relationships?

This is the point where most beginners struggle in Low-Level Design interviews.

They understand concepts individually, but fail to transform requirements into a clean object model.

The Real Problem in LLD

Given a question like:

• Design a parking lot
• Design Uber
• Design a food delivery system
• Design Splitwise

Most people immediately start writing:

• classes
• methods
• APIs

But real design does not begin with code.

It begins with:

• understanding the domain
• identifying responsibilities
• discovering system structure

Step 1: Start with Requirements, Not Classes

Before thinking about objects, first understand:

What does the system need to do?

These are:

• functional requirements
• user actions
• system capabilities

What constraints exist?

These include:

• scale
• business rules
• operational limitations

Without requirement clarity:

• classes become random
• abstractions become weak
• systems become inconsistent

Step 2: Extract Candidate Entities from Requirements

A simple but powerful approach:

Convert problem statements into nouns.

Example: Food Delivery System

From requirements, you may identify:

• User
• Restaurant
• Dish
• Cart
• Order
• Payment
• DeliveryPartner
• Vehicle

These become:

candidate entities

Not all will become final classes, but this gives a strong starting point.

Step 3: Filter Entities Using Responsibility Thinking

Not every noun deserves to become a class.

The important question is:

Does this entity own meaningful state or behavior?

Example

Strong entity candidates

• Order
• Cart
• Payment
• DeliveryPartner

These have:

• state
• lifecycle
• behavior

Possible supporting objects

• Address
• Coordinates
• Money

These may become:

• value objects
• supporting models
• reusable structures

Step 4: Assign Responsibilities

This is one of the most important steps in OOD.

Ask:

What should this entity be responsible for?

Example

Order

Responsible for:

• maintaining order state
• tracking lifecycle
• validating status transitions

PaymentService

Responsible for:

• processing payments
• handling payment methods
• communicating with gateways

DeliveryPartner

Responsible for:

• accepting deliveries
• updating delivery progress
• managing availability state

Step 5: Identify Relationships Between Entities

Now think about interactions.

Questions to ask:

• Who owns whom?
• Who depends on whom?
• Which objects collaborate together?

Example Relationships

• Cart → belongs to User
• Order → created from Cart
• Order → uses PaymentService
• DeliveryPartner → assigned to Order

At this stage:

focus on relationships, not implementation

Step 6: Discover Behaviors Before Methods

Do not immediately think in code syntax.

Instead ask:

• What actions happen in the system?
• Which object should own those actions?

Example

Instead of randomly writing:

process_payment()

Think:

• who should process payment?
• PaymentService?
• Order?
• external gateway?

This improves responsibility placement.

Step 7: Convert Structure into Classes

Only now should you move toward:

• classes
• interfaces
• services
• dependencies

At this point, the design becomes:

• intentional
• structured
• easier to evolve

Key Mental Model

Good LLD follows this flow:

Requirements
→ Entities
→ Responsibilities
→ Relationships
→ Behaviors
→ Classes
→ Code

Skipping steps leads to weak design.

Common Mistakes

Beginners often:

• jump directly into coding
• force design patterns early
• create unnecessary classes
• ignore responsibility ownership

This creates:

• poor abstractions
• tight coupling
• confusing systems

Why This Skill Matters

This requirement-to-design mapping skill is the foundation of:

• Domain Modeling
• Real-world system design
• LLD interviews
• scalable architecture thinking

Without it:

• designs remain mechanical
• systems feel artificial
• interviews become difficult

Real Insight

The hardest part of object-oriented design is not writing classes — it is discovering the right responsibilities from the problem itself.

One-Line Takeaway

Great LLD starts by understanding the domain deeply enough to discover the right objects, responsibilities, and relationships before writing code.