Identifying classes from requirements in LLD - System Design Guide

Problem Statement

When developers start coding without clearly identifying the main classes, the design becomes messy and hard to maintain. This leads to duplicated code, unclear responsibilities, and difficulty in extending the system later.

Solution

By carefully analyzing the requirements, we find the main nouns and verbs that represent objects and actions. We then create classes for these objects with clear responsibilities, which helps organize the code logically and makes it easier to maintain and extend.

Architecture

Requirements

→Identify Nouns

↓

Define Classes with

Define Classes with

This diagram shows the flow from requirements to identifying nouns and then defining classes with clear responsibilities.

Trade-offs

✓ Pros

→

Improves code organization by mapping real-world concepts to classes.

→

Makes the system easier to understand and maintain.

→

Helps identify clear responsibilities for each class, reducing duplicated code.

✗ Cons

→

Requires careful reading and interpretation of requirements, which can be time-consuming.

→

May lead to too many small classes if over-applied, increasing complexity.

→

Initial design might miss some classes if requirements are incomplete or ambiguous.

Use this approach when starting a new system or feature with clear textual requirements and when maintainability and clarity are priorities.

Avoid relying solely on this when requirements are vague, rapidly changing, or when prototyping quickly without focus on design.

Real World Examples

Amazon

Amazon identifies classes like Order, Customer, and Product from requirements to organize their e-commerce system logically.

Uber

Uber models classes such as Driver, Rider, and Trip from their ride-sharing requirements to separate concerns clearly.

LinkedIn

LinkedIn uses class identification from requirements to define entities like User, Connection, and Message for their social network.

Code Example

The before code mixes customer and order logic in one function, making it hard to maintain. After identifying classes Customer and Order from requirements, responsibilities are separated, improving clarity and extensibility.

LLD

### Before: No clear classes, everything in one function

def process_order(order_data):
    print(f"Processing order for {order_data['customer_name']}")
    # code mixes customer and order logic


### After: Classes identified from requirements

class Customer:
    def __init__(self, name):
        self.name = name

class Order:
    def __init__(self, customer):
        self.customer = customer

    def process(self):
        print(f"Processing order for {self.customer.name}")

# Usage
customer = Customer("Alice")
order = Order(customer)
order.process()

Alternatives

Entity-Relationship Modeling

Focuses on data entities and their relationships rather than behavior and responsibilities.

Use when: Choose when the system is data-centric and database design is the priority.

Use Case Driven Design

Starts from user interactions and scenarios rather than nouns in requirements.

Use when: Choose when user workflows and interactions are the main focus.

Summary

Identifying classes from requirements prevents messy, unorganized code by mapping real-world concepts to code.

It involves finding key nouns and defining classes with clear responsibilities to improve maintainability.

This approach is best when requirements are clear and stable, helping build a solid foundation for the system.