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.

Practice

1. What is the main purpose of Domain-Driven Design (DDD)?

easy

A. To model software closely around real business concepts

B. To optimize database queries for performance

C. To create user interfaces quickly

D. To write code without any documentation

Solution

1. Step 1: Understand the goal of DDD

   DDD focuses on aligning software design with the core business domain and its logic.

2. Step 2: Compare options with DDD purpose

   Only To model software closely around real business concepts describes modeling software around business concepts, which is the essence of DDD.

3. Final Answer:

   To model software closely around real business concepts -> Option A

4. Quick Check:

   DDD = model software on business concepts [OK]

Hint: DDD = software models business ideas clearly [OK]

Common Mistakes:

• Confusing DDD with UI or database optimization
• Thinking DDD is about coding speed only
• Ignoring the business domain focus

2. Which of the following is the correct definition of an Entity in DDD?

easy

A. An object defined only by its attributes and no identity

B. A database table storing raw data

C. An object with a unique identity that persists over time

D. A service that performs calculations without state

Solution

1. Step 1: Recall Entity characteristics in DDD

   Entities have a unique identity that remains constant even if attributes change.

2. Step 2: Match definitions with Entity concept

   An object with a unique identity that persists over time correctly states that Entities have unique identity and persistence over time.

3. Final Answer:

   An object with a unique identity that persists over time -> Option C

4. Quick Check:

   Entity = unique identity object [OK]

Hint: Entity always has unique identity, not just attributes [OK]

Common Mistakes:

• Confusing Entities with Value Objects
• Thinking Entities have no identity
• Mixing Entities with Services

3. Consider this simplified DDD code snippet in Python:

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

order1 = Order(1, ['apple', 'banana'])
order2 = Order(1, ['apple', 'banana'])

print(order1 == order2)

What will be the output?

medium

A. True

B. False

C. SyntaxError

D. None

Solution

1. Step 1: Understand default equality in Python classes

   By default, Python compares object references, so two different instances with same data are not equal.

2. Step 2: Analyze the code output

   order1 and order2 are different objects with same data, so order1 == order2 returns False.

3. Final Answer:

   False -> Option B

4. Quick Check:

   Default object equality compares references = False [OK]

Hint: Default == compares object identity, not data [OK]

Common Mistakes:

• Assuming == compares data automatically
• Expecting True because attributes match
• Confusing syntax error with logic error

4. In a DDD model, a Value Object should be immutable. Which of the following code snippets violates this principle?

medium

A. class Money:
def __init__(self, amount, currency):
self.amount = amount
self.currency = currency

B. class Money:
def __init__(self, amount, currency):
self._amount = amount
self._currency = currency

C. class Money:
def __init__(self, amount, currency):
self._amount = amount
self._currency = currency
@property
def amount(self):
return self._amount

D. class Money:
def __init__(self, amount, currency):
self.amount = amount
self.currency = currency
def change_amount(self, new_amount):
self.amount = new_amount

Solution

1. Step 1: Recall immutability in Value Objects

   Value Objects should not allow changes after creation to keep consistency.

2. Step 2: Identify mutable code

   class Money: def __init__(self, amount, currency): self.amount = amount self.currency = currency def change_amount(self, new_amount): self.amount = new_amount has a method that changes the amount, violating immutability.

3. Final Answer:

   Code with method changing amount violates immutability -> Option D

4. Quick Check:

   Value Object must be immutable = no setters [OK]

Hint: Value Objects cannot change state after creation [OK]

Common Mistakes:

• Allowing setters or methods that modify attributes
• Confusing immutability with read-only properties only
• Ignoring methods that change internal state

5. You are designing a DDD model for an online store. Which of the following best represents an Aggregate?

hard

A. An Order object that contains multiple OrderItems and enforces business rules

B. A single Product object with price and description

C. A database table storing customer addresses

D. A utility service that calculates discounts

Solution

1. Step 1: Understand Aggregate in DDD

   An Aggregate is a cluster of related objects treated as a single unit with a root entity controlling consistency.

2. Step 2: Match options with Aggregate concept

   An Order object that contains multiple OrderItems and enforces business rules describes an Order with multiple OrderItems and business rules, fitting Aggregate definition.

3. Final Answer:

   An Order object containing multiple OrderItems and enforcing business rules -> Option A

4. Quick Check:

   Aggregate = root entity + related objects [OK]

Hint: Aggregate = root entity plus related objects as one unit [OK]

Common Mistakes:

• Confusing single entities with aggregates
• Thinking utility services are aggregates
• Mixing database tables with domain aggregates