Domain-Driven Design basics in LLD - System Design Guide

Problem Statement

When software models do not match the real-world business domain, teams struggle with unclear requirements, frequent misunderstandings, and code that is hard to change or extend. This leads to slow development, bugs, and systems that do not meet user needs.

Solution

Domain-Driven Design (DDD) solves this by focusing on the core business domain and building software models that reflect it closely. It encourages collaboration between developers and domain experts to create a shared language and clear boundaries, making the system easier to understand and evolve.

Architecture

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│  Domain       │──────▶│  Application  │──────▶│  Infrastructure│
│  Model        │       │  Layer        │       │  Layer        │
└───────────────┘       └───────────────┘       └───────────────┘
        ▲                      │                       │
        │                      │                       │
        └──────────────────────┴───────────────────────┘

This diagram shows the separation of concerns in DDD: the Domain Model contains business logic, the Application Layer coordinates tasks, and the Infrastructure Layer handles technical details like databases.

Trade-offs

✓ Pros

→

Aligns software design closely with business needs, reducing misunderstandings.

→

Improves communication between developers and domain experts through a shared language.

→

Creates modular code with clear boundaries, making maintenance and scaling easier.

→

Helps manage complexity by focusing on the core domain and separating concerns.

✗ Cons

→

Requires significant upfront collaboration and learning, which can slow initial development.

→

May introduce complexity if applied to simple or small projects unnecessarily.

→

Needs continuous effort to keep the domain model and code aligned as business evolves.

Use DDD when building complex business applications with evolving requirements and multiple stakeholders, typically when the domain is rich and central to the system's success.

Avoid DDD for simple CRUD applications or projects with very stable, straightforward requirements where the overhead of domain modeling is not justified.

Real World Examples

Amazon

Amazon uses DDD to manage its complex e-commerce domain, separating concerns like ordering, payment, and inventory into distinct bounded contexts to handle scale and complexity.

Netflix

Netflix applies DDD principles to model its streaming domain, enabling teams to work independently on different parts like user management and content delivery.

Airbnb

Airbnb uses DDD to align its platform's business rules with software, managing domains such as bookings, payments, and user profiles with clear boundaries.

Code Example

Before applying DDD, business logic and data handling are mixed, making the code harder to maintain. After applying DDD, the domain concepts like Money and OrderItem encapsulate behavior, making the model clearer and easier to extend.

LLD

### Before DDD: Business logic mixed with data access
class Order:
    def __init__(self, items):
        self.items = items

    def total_price(self):
        total = 0
        for item in self.items:
            total += item['price'] * item['quantity']
        return total

# Data access and business logic are mixed

### After DDD: Clear domain model with business logic encapsulated
class Money:
    def __init__(self, amount):
        self.amount = amount

    def add(self, other):
        return Money(self.amount + other.amount)

class OrderItem:
    def __init__(self, product, quantity, price):
        self.product = product
        self.quantity = quantity
        self.price = price

    def total_price(self):
        return Money(self.price * self.quantity)

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

    def total_price(self):
        total = Money(0)
        for item in self.items:
            total = total.add(item.total_price())
        return total

Alternatives

Layered Architecture

Focuses on technical separation (UI, business logic, data) rather than domain complexity and language.

Use when: Choose when the system is simple or when domain complexity is low and technical separation suffices.

Event-Driven Architecture

Centers on asynchronous events and messaging rather than domain modeling and shared language.

Use when: Choose when decoupling components and handling high scalability or real-time data flows are priorities.

Summary

Domain-Driven Design helps build software that closely matches complex business domains.

It encourages collaboration and a shared language between developers and domain experts.

DDD organizes code into clear models and boundaries, improving maintainability and scalability.