Domain-Driven Design (DDD) basics in Microservices - System Design Guide

Problem Statement

When software systems grow complex, teams often struggle to keep the code aligned with real business needs. This leads to tangled code, unclear responsibilities, and slow feature delivery because developers and domain experts speak different languages.

Solution

Domain-Driven Design solves this by organizing software around the core business concepts and language. It breaks the system into clear domains and subdomains, each with its own model and logic, ensuring developers and business experts share a common understanding. This alignment helps build maintainable, flexible systems that evolve with business changes.

Architecture

User Interface

(Frontend)

→Application

↓

Infrastructure

Infrastructure

This diagram shows how DDD structures a system into layers: the user interface, application logic, domain logic with business rules, and infrastructure for technical details. The domain layer is central, representing the core business concepts.

Trade-offs

✓ Pros

→

Improves communication between developers and business experts by using a shared language.

→

Keeps business logic isolated, making the system easier to maintain and evolve.

→

Supports building microservices aligned with business capabilities, improving scalability.

→

Helps manage complexity by dividing the system into bounded contexts.

✗ Cons

→

Requires significant upfront collaboration and domain knowledge gathering.

→

Can add complexity if applied to small or simple systems unnecessarily.

→

Needs ongoing effort to keep domain models and code synchronized with business changes.

Use DDD when building complex business systems with multiple teams and evolving requirements, especially when microservices need clear boundaries aligned with business domains.

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 organize its vast e-commerce platform into bounded contexts like ordering, inventory, and payment, enabling independent teams to develop and scale services aligned with business capabilities.

Netflix

Netflix applies DDD principles to separate concerns like user management, streaming, and recommendations into distinct domains, allowing rapid innovation and scaling of individual services.

Uber

Uber uses DDD to model complex domains such as ride matching, payments, and driver management, helping to keep business logic clear and services decoupled.

Code Example

The before code mixes validation, calculation, and data saving in one method, making it hard to maintain. The after code separates concerns: Order and OrderItem represent the domain model with business logic, OrderRepository handles data persistence, and OrderService coordinates actions. This clear separation follows DDD principles.

Microservices

### Before applying DDD - tangled business logic mixed with data access
class OrderService:
    def create_order(self, user_id, items):
        # Validate items
        if not items:
            raise ValueError("No items")
        # Calculate total
        total = sum(item['price'] * item['qty'] for item in items)
        # Save order directly
        order = {'user_id': user_id, 'items': items, 'total': total}
        database.save(order)
        return order


### After applying DDD - clear domain model and separation

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

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

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

    def add_item(self, item: OrderItem):
        self.items.append(item)

    def total(self):
        return sum(item.total_price() for item in self.items)

class OrderRepository:
    def save(self, order: Order):
        # Persist order to database
        pass

class OrderService:
    def __init__(self, repository: OrderRepository):
        self.repository = repository

    def create_order(self, user_id, items_data):
        if not items_data:
            raise ValueError("No items")
        order = Order(user_id)
        for data in items_data:
            item = OrderItem(data['product_id'], data['price'], data['quantity'])
            order.add_item(item)
        self.repository.save(order)
        return order

Alternatives

Layered Architecture

Focuses on technical layers (UI, business, data) without explicit domain modeling or bounded contexts.

Use when: Use when the system is simple or domain complexity is low, and clear separation of technical concerns is sufficient.

Event-Driven Architecture

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

Use when: Choose when system needs high scalability and loose coupling, especially for real-time or distributed systems.

Service-Oriented Architecture (SOA)

Focuses on reusable services often aligned with business functions but may lack the deep domain modeling focus of DDD.

Use when: Use when integrating legacy systems or when services need to be shared across multiple applications.

Summary

Domain-Driven Design aligns software structure with business concepts to manage complexity.

It divides systems into bounded contexts with clear domain models and shared language.

DDD improves maintainability and team collaboration, especially in complex microservices architectures.