DEV Community

Saras Growth Space
Saras Growth Space

Posted on

LLD Object-Oriented Design: From Requirements to Classes (Bridging Thinking to Domain Modeling)

#lld #systemdesign #softwareengineering #codinginterview

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()
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)