Domain-Driven Design — Modelling Complex Domains

How do you split a monolith into microservices? By database table? By UI page? Wrong. By business domain. Eric Evans’s Domain-Driven Design provides a framework for modelling complex systems — and bounded contexts are the ideal boundaries for microservices.

Bounded Context¶

A bounded context is an explicit boundary within which the domain model is valid. “Customer” in CRM is different from “Customer” in billing. Same word, different context, different model. Each bounded context = a candidate for a microservice.

Ubiquitous Language¶

DDD requires a shared language between developers and business experts. When the business says “order,” the code has a class Order, not TransactionRecord. The language of the code = the language of the domain. No translations.

Aggregates and Entities¶

Entity: Objects with identity (Order, Customer). Lifecycle, state changes. Value Object: Objects without identity (Money, Address). Immutable. Aggregate: A cluster of objects with a root entity. Transactional boundary. Rule: modifications only through the Aggregate Root.

public class Order { // Aggregate Root
    private OrderId id;
    private List<OrderLine> lines;
    private OrderStatus status;

    public void addLine(Product product, int quantity) {
        if (status != DRAFT) throw new IllegalStateException();
        lines.add(new OrderLine(product, quantity));
    }

    public void submit() {
        if (lines.isEmpty()) throw new IllegalStateException();
        status = SUBMITTED;
        registerEvent(new OrderSubmitted(id));
    }
}

Context Mapping¶

How do bounded contexts communicate? Shared Kernel (shared model), Customer-Supplier (upstream/downstream), Anti-Corruption Layer (translation between models). For microservices typically ACL — each service protects its own model.

DDD is an Investment That Pays Off¶

DDD is not for every project — for CRUD applications it is overkill. But for complex domain logic and correctly splitting microservices, it is invaluable.