LLD Object-Oriented Design: System Layers (Structuring Real Systems)

After understanding objects, relationships, dependency injection, and factories, the next step is learning how to organize everything into a real system.

Because writing good classes is not enough.

A system becomes maintainable only when responsibilities are correctly distributed across layers.

---

Why System Layers Exist

In real applications:

• business logic grows
• external integrations increase
• complexity spreads quickly

Without structure:

• everything gets mixed
• changes become risky
• debugging becomes difficult

System layers solve this by separating responsibilities.

---

Common Layered Architecture

A typical LLD system is divided into:

• Controller Layer
• Service Layer
• Domain Layer (Entities)
• Infrastructure Layer

---

1. Controller Layer

The controller is the entry point.

It is responsible for:

• receiving input
• validating basic data
• calling services

---

Example

def place_order(request):
    return order_service.place_order(request)

---

Key Rule

Controllers should NOT contain business logic.

---

2. Service Layer

The service layer contains business logic.

It is responsible for:

• orchestrating workflows
• applying business rules
• coordinating multiple components

---

Example

class OrderService:
    def place_order(self, user, cart):
        order = Order(user, cart)
        order.mark_created()
        self.payment.pay(cart.total)
        return order

---

3. Domain Layer (Entities)

Entities represent core business objects.

They:

• hold state
• enforce rules
• manage their own behavior

---

Example

class Order:
    def mark_created(self):
        self.status = "CREATED"

---

Key Idea

Entities are not just data holders — they are behavior-rich models.

---

4. Infrastructure Layer

This layer handles external systems:

• databases
• APIs
• messaging systems
• external services

---

Example

class PaymentGateway:
    def pay(self, amount):
        pass

---

Why Layering is Important

Without layers:

• services become bloated
• logic becomes scattered
• dependencies become unclear

With layers:

• responsibilities are isolated
• code becomes predictable
• scaling becomes easier

---

Flow of Control

A typical system flow looks like:

Controller → Service → Entity → Infrastructure

Each layer has a clear responsibility boundary.

---

Key Design Insight

Each layer should depend only on the layer below it, not across unrelated layers.

---

Common Mistake

Beginners often:

• put business logic in controllers
• mix infrastructure calls inside services
• make entities passive data structures

This leads to:

• tight coupling
• low cohesion
• difficult maintenance

---

Clean Design Principle

Separate what the system does (business logic) from how it interacts with external systems (infrastructure).

---

Real-World Analogy

Think of a restaurant:

• Customer → Controller
• Chef → Service
• Recipe → Entity
• Suppliers → Infrastructure

Each has a clear role and responsibility.

---

One-Line Takeaway

System layers organize responsibilities so that each part of the system has a single, clear purpose.