LLD Roadmap

A. Curriculum overview

This curriculum takes a learner from "I know OOP syntax" to being able to design an unfamiliar system by reasoning from requirements. It is built around one idea: patterns are introduced as solutions to problems the learner has already experienced.

The progression

Programming / OOP
      ↓
Object Thinking
      ↓
Object Modeling
      ↓
Cohesion / Coupling
      ↓
SOLID + Design Principles
      ↓
Dependencies + Interfaces
      ↓
UML + Object Interactions
      ↓
Design Patterns
      ↓
Pattern Combinations
      ↓
Small Design Exercises
      ↓
Complete LLD Problems
      ↓
Refactoring
      ↓
Advanced Design Thinking
      ↓
Interview-ready Design

What makes this different from a typical LLD course

Patterns are introduced as solutions to problems the learner has already experienced, not as a catalog to memorize.

B. Phase 1: Foundations and design intuition (weeks 1 to 4)

Week 1: Object-oriented thinking

Goal: Move from "I know OOP syntax" to "I know how to think in objects."

Time: about 10 hours, 9 lessons.

Module 1: Classes, objects and responsibilities

Small exercises

BankAccount
ShoppingCart
User / Address
Order / OrderItem
Employee / Department

For each exercise, identify:

→ objects
→ state
→ behavior
→ responsibilities
→ collaborators

Critical exercise

Give the learner: "Design a shopping cart." Do not ask for code first. Ask:

What objects exist?
Who owns the items?
Who calculates total?
Who applies discount?
Who handles payment?

This starts developing the design questions the learner should eventually ask unprompted.

Week 2: Relationships and object modeling

Goal: Learn to convert requirements into an object model.

Time: about 10 hours, 9 lessons, plus the UML lessons (see section D).

Module 2: Modeling objects

Worked example

Requirement:

A library has books. Members can borrow books. A book can be borrowed by one member at a time.

The learner should arrive at something like:

Library
   |
   ├── Book
   |
   └── Member

Book
 └── Borrowing

Member
 └── Borrowing

Then ask:

Who owns Borrowing?
Who creates it?
Who ends it?
Where is the rule "one active borrower" enforced?

This moves the learner from class identification to responsibility assignment.

Exercises

1. Library
2. Deck of Cards
3. Coffee Machine
4. Vending Machine

These are deliberately introduced before the larger interview problems rather than dumped into an interview-question list.

Week 3: Design principles

Goal: Learn why designs become difficult to maintain.

Time: about 10 hours, 12 lessons.

Module 3: Principles

SOLID

Supporting principles

Teaching format

Every principle follows the same path:

Problem
 ↓
Naive design
 ↓
Why it hurts
 ↓
Refactoring
 ↓
Principle
 ↓
Improved design
 ↓
When NOT to apply it

This is better than stating "SRP means one class should have one responsibility." The learner should experience the design pressure first.

Worked example

Bad design:

class OrderService {
    createOrder()
    calculateTax()
    sendEmail()
    generateInvoice()
    saveToDatabase()
}

Then progressively ask: what changes independently?

Tax rules
Email provider
Invoice format
Database
Order logic

Now SRP becomes intuitive.

Week 4: Dependencies, interfaces and modeling

Goal: Understand how objects depend on one another and how to control those dependencies.

Time: about 10 hours, 9 lessons.

Module 4: Dependency management

Java and Spring connection

Only now introduce:

@Service
@Component
@Repository
@Autowired
constructor injection

The learner should understand why Spring's dependency injection exists, rather than merely learning Spring annotations.

Practical exercise

Start with a class tied to a concrete implementation:

class OrderService {
    private MySQLOrderRepository repository;
}

Introduce an interface:

interface OrderRepository {
    save(Order order);
}

class MySQLOrderRepository implements OrderRepository {
}

Then inject it through the constructor:

class OrderService {

    private final OrderRepository repository;

    OrderService(OrderRepository repository) {
        this.repository = repository;
    }
}

Then discuss:

testability
dependency direction
substitution
coupling
interface ownership

Phase 1 integration project: Design a Notification System

At the end of week 4, do not jump straight into GoF patterns. Give one open-ended design exercise.

Requirements:

Send notification through:
→ Email
→ SMS
→ Push

Users can have notification preferences.

Different notification types may exist:
→ marketing
→ transaction
→ security

The learner must produce:

1. Requirements
2. Objects
3. Responsibilities
4. Relationships
5. Interfaces
6. Class diagram
7. Sequence diagram
8. Code
9. Refactoring discussion

This combines the first four weeks.

Phase 1 outcome: a strong hold on fundamentals. The learner can take a small requirement and produce a reasonable object model.

C. Phase 2: Patterns and real LLD (weeks 5 to 7)

Patterns begin here. The sequencing is deliberate: patterns should not precede understanding of the underlying design problem.

Week 5: Design patterns

Goal: Understand patterns as reusable design solutions.

Time: about 10 hours.

Do not teach all 23 patterns equally.

Pattern tiers

This prevents the common mistake of spending equal time on every GoF pattern.

Learning order

Start with behavioral patterns, not creational ones, because they solve the problems developers feel most directly.

Behavioral

Example for lesson 40, where the learner discovers Strategy:

PaymentStrategy
    ↑
 ┌──┴─────┐
Card    UPI

Creational

Structural

Pattern lesson structure

Every pattern article contains exactly this structure:

1. Problem
2. Naive solution
3. Why the naive solution breaks
4. Forces / trade-offs
5. Pattern
6. Object relationships
7. Implementation
8. Real-world example
9. When to use
10. When NOT to use
11. Recognition clues
12. Similar patterns
13. Small exercise
14. Recall questions

Week 6: Pattern combinations and complete LLD

Goal: Stop thinking in isolated patterns. Real systems frequently combine them.

Time: about 10 hours.

Module 5: Pattern combinations

Every combination lesson follows:

Why one pattern isn't enough
↓
Responsibilities
↓
Object graph
↓
Interaction
↓
Trade-offs

Complete LLD problem progression

Do not make every problem a two-hour interview exercise. Each problem follows:

Understand
 ↓
Model
 ↓
Implement
 ↓
Refactor
 ↓
Extend
 ↓
Explain

Level 1: Beginner

Level 2: Intermediate

Level 3: Advanced LLD

Level 4: Design engineer

These are less about standard interview templates and more about genuine design ability.

Week 7: Refactoring and advanced design thinking

Goal: Learn to evaluate and improve designs rather than simply create them.

Time: about 10 hours, plus mock interviews.

Refactoring is an essential part of the curriculum, not an optional appendix.

Module 6: Code smells

Each lesson follows:

Bad design
 ↓
Identify smell
 ↓
Why it happens
 ↓
Principle violated
 ↓
Refactoring
 ↓
Improved design

Module 7: Advanced design thinking

These lessons stay at the object and component level rather than turning into an HLD course.

Phase 2 outcome: a strong hold on cross-implementation. The learner can meet an unfamiliar requirement and construct, explain, critique and evolve a design.

D. UML curriculum

UML is taught alongside design, not as a separate week of notation memorization. It is limited to the practical subset needed for LLD.

How to choose:

• "What are the objects?" leads to a class diagram.
• "How do objects collaborate over time?" leads to a sequence diagram.

E. The requirement-to-design algorithm

This is the central mental model of ProgVale LLD. Every serious design exercise forces the learner through it, and it should appear repeatedly throughout the course.

1. Requirements
       ↓
2. Use cases
       ↓
3. Entities
       ↓
4. Responsibilities
       ↓
5. Relationships
       ↓
6. State
       ↓
7. Interfaces
       ↓
8. Changing behavior
       ↓
9. Abstractions
       ↓
10. Principles
       ↓
11. Patterns
       ↓
12. Object interactions
       ↓
13. Extensibility
       ↓
14. Trade-offs
       ↓
15. Code
       ↓
16. Refactor

The learner eventually should not ask, "Which pattern does this question require?" They should ask:

• What is changing?
• Who owns this behavior?
• What depends on what?
• Where is the coupling?
• What should be replaceable?
• Do I actually need an abstraction?

That is the real LLD skill.

F. Small design exercise bank

These exercises sit between theory and complete LLD problems. Each reinforces one specific concept rather than being an arbitrary interview question.

G. The ProgVale lesson format

Every article follows one consistent template that fits the 10 to 25 minute format and the Learn, Practice, Recall, Apply, Integrate model.

Title: {Lesson Title}

Learning Objective
  By the end of this lesson you should be able to...

Prerequisites
  You should already understand...

The Problem
  Start with a real design problem.

Concept
  Explain the theory.

Example
  Show a small Java or Python example.

Bad Design
  Show the naive implementation.

Why It Is Bad
  Explain the design consequences.

Better Design
  Refactor.

Design Thinking
  Explain how we arrived at the design.

Small Exercise
  Implement...

Can You Explain?
  1. ...
  2. ...
  3. ...

Can You Design?
  Given...

Completion Criteria
  You are done when you can...

Recall
  Review this concept later.

H. Spaced learning architecture

This is where ProgVale can be better than a static LLD course. Concepts must not be learned once and then never seen again.

Avoid:

SRP → OCP → LSP → ISP → DIP → never seen again

Instead, resurface each principle across later work:

Learn SRP
   ↓
Small SRP exercise
   ↓
Parking Lot
   ↓
Notification System
   ↓
Splitwise
   ↓
Payment System
   ↓
Refactoring exercise

The same applies to patterns:

Strategy
   ↓
Discount Engine
   ↓
Parking Lot
   ↓
Payment System
   ↓
Ride Pricing
   ↓
Rule Engine

I. Dependency maps

Concept dependency graph

                    Programming Basics
                           │
                           ▼
                    Classes & Objects
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
       Encapsulation    Abstraction    State
             │             │             │
             └──────┬──────┴──────┬──────┘
                    ▼             ▼
              Responsibilities   Behavior
                    │             │
                    └──────┬──────┘
                           ▼
                   Object Modeling
                           │
             ┌─────────────┼──────────────┐
             ▼             ▼              ▼
       Relationships    Cohesion       Coupling
             │             │              │
             └─────────────┼──────────────┘
                           ▼
                    Design Principles
                           │
                    ┌──────┴──────┐
                    ▼             ▼
                  SOLID      DRY/KISS/YAGNI
                    │
                    ▼
              Interfaces / DI
                    │
                    ▼
             Dependency Direction
                    │
                    ▼
              Object Interaction
                    │
             ┌──────┴───────┐
             ▼              ▼
            UML        Design Process
             │              │
             └──────┬───────┘
                    ▼
             Design Problems
                    │
                    ▼
             Design Patterns
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
      Creational Structural Behavioral
          │         │         │
          └─────────┼─────────┘
                    ▼
            Pattern Combinations
                    │
                    ▼
             Complete LLD
                    │
                    ▼
                Refactoring
                    │
                    ▼
          Advanced Design Thinking
                    │
                    ▼
             Interview Ready
                    │
                    ▼
            Strong LLD Engineer

Pattern dependency graph

Patterns have their own prerequisites. This is more educational than the usual Creational, Structural, Behavioral classification.

Interfaces → Polymorphism → Strategy → Factory → Strategy + Factory

Composition → Decorator → Decorator + Factory

Object collaboration → Observer → Mediator → Observer + Mediator

State modeling → State → State + Strategy

Request pipeline → Chain of Responsibility → Chain + Strategy

Actions as objects → Command → Command + Memento

Tree structures → Composite → Composite + Visitor

J. Priorities: what to know

Must know deeply

Should know

Abstract Factory, Singleton, Bridge, Mediator, Iterator, Memento, Flyweight, plugin architecture, value objects, entities, aggregates, hexagonal architecture.

Awareness

Prototype, Visitor, Interpreter. The learner should recognize these and understand their purpose, but should not spend disproportionate time memorizing implementations.

K. Time allocation and phase summary

70-hour allocation

The allocation is intentionally weighted toward design thinking and application, rather than spending 25 hours memorizing GoF patterns.

Phase 1 vs Phase 2

L. Interview progression

The learner moves through four stages. ProgVale should optimize for Stage 4.

M. What typical LLD courses get wrong

1. They teach patterns too early

Typical course order:

OOP → Factory → Singleton → Builder → Adapter → ...

The learner knows the diagram but not when the problem actually requires the pattern. ProgVale uses this order instead:

problem → naive solution → pain → design principle → pattern

2. They confuse UML knowledge with design knowledge

Knowing the symbols (◇ ◆ △ →) does not make someone good at LLD. UML should communicate a design, not become the objective.

3. They teach SOLID as definitions

"Open/Closed Principle means software should be open for extension but closed for modification" teaches nothing on its own. Instead:

Add payment method
        ↓
Modify giant if/else
        ↓
Repeated regression
        ↓
Why is this happening?
        ↓
What should vary?
        ↓
Strategy
        ↓
OCP

4. They do not teach responsibility assignment

This is one of the biggest missing skills. A learner needs to repeatedly answer: who should own this behavior?

Who calculates parking fee?

ParkingLot?
Ticket?
Vehicle?
PricingStrategy?
ParkingSpot?

There is not always one universal answer. The learner must learn to reason about the trade-offs.

5. They do not teach when NOT to abstract

Bad LLD education teaches:

Interface → Abstract class → Factory → FactoryFactory

Good LLD teaches: do not create an abstraction until you have a reason. This connects directly to YAGNI, KISS and avoiding overengineering.

6. They do not teach refactoring

Most courses show the beautiful final design. Real engineers encounter:

legacy code → bad coupling → God class → unclear ownership → incremental refactoring

Refactoring therefore gets its own module, not a few interview tips.

7. They do not teach design evolution

The most important question is not "does this design work?" but "what happens when requirements change?" Every major ProgVale problem therefore has:

Version 1
   ↓
New requirement
   ↓
What breaks?
   ↓
Refactor
   ↓
Version 2

This is probably the single strongest differentiator to build into ProgVale.

N. The golden rule and the final target

The golden rule for every article

Every lesson should answer at least one of these questions:

• What problem does this solve?
• Why does the naive design fail?
• Who should own this behavior?
• What should change independently?
• What is coupled to what?
• Where should the abstraction live?
• Do we actually need a pattern?
• What happens when the requirement changes?

That turns the curriculum from a "23 design patterns plus 20 interview questions" course into an actual software design training system.

Final curriculum size

Target about 100 to 110 substantial lessons, not 150 or more tiny ones. The first 85 form the structured learning path; the remainder cover integration, refactoring, advanced design and repeated application. A learner doing 10 hours a week can complete the core path in 7 weeks, and ProgVale can keep resurfacing earlier concepts through spaced practice afterward.

The ultimate competency

New requirement
      ↓
What objects exist?
      ↓
Who owns each responsibility?
      ↓
How do they collaborate?
      ↓
What changes independently?
      ↓
Where is the coupling?
      ↓
Do I need an abstraction?
      ↓
Would a pattern actually help?
      ↓
What are the trade-offs?
      ↓
How will the design evolve?

That is the LLD skill ProgVale should teach: not the ability to reproduce a Parking Lot solution from memory.