Welcome to the Masterclass

Every developer has felt it: a codebase that started clean and, two years later, fights back against every change. A "simple" new rule touches eleven files. Nobody is sure what status = 3 means. The bug you just fixed comes back wearing a different hat.

That pain is rarely about a missing framework or a slow database. It's about a model that drifted away from how the business actually thinks. Domain-Driven Design (DDD) is a set of practices — some about people and conversations, some about code — for keeping that model honest, expressive, and changeable as the business evolves.

What this course covers

DDD has two halves, and most courses teach only one. We teach both, in the order you'd actually use them on a real project.

Strategic design — the big picture

Before any code, you learn to discover the domain and carve it into pieces that make sense: subdomains, the all-important bounded context, the ubiquitous language, and the context maps that describe how the pieces relate. This is the half that decides whether a system stays maintainable for years.

Tactical design — the code

Then you build the model itself: entities, value objects, aggregates that enforce business rules, domain services, repositories, and domain events. Every pattern is shown as real Java 21 / Spring Boot code, not pseudocode.

Architecture & scale — making it last

Finally you wire it all together: hexagonal and clean architecture, CQRS, event sourcing, and the choice between a modular monolith and microservices — with the judgment to know which one a given problem actually needs.

One domain, all the way through: ShopSphere

Switching examples every lesson is exhausting and shallow. Instead, you'll build a single, believable system — ShopSphere, an online retail platform — and return to it from every angle. By the capstone you'll have modeled its whole landscape:

Here's the kind of code you'll be writing by Section 9 — an aggregate that refuses to enter an invalid state:

Order.java — an aggregate root protecting its own invariants

@AggregateRoot
public class Order {

    private final OrderId id;
    private final CustomerId customer;
    private final List<OrderLine> lines = new ArrayList<>();
    private OrderStatus status = OrderStatus.DRAFT;

    // Behavior, not setters: the rule lives with the data it protects.
    public void addLine(Sku sku, Quantity qty, Money unitPrice) {
        if (status != OrderStatus.DRAFT) {
            throw new OrderAlreadyPlacedException(id);
        }
        lines.add(new OrderLine(sku, qty, unitPrice));
    }

    public Money total() {
        return lines.stream()
                    .map(OrderLine::subtotal)
                    .reduce(Money.zero("USD"), Money::add);
    }
}

How to get the most from this course

1. Read in order, at least the first time The course is deliberately sequenced: strategy before tactics, simple before scaled. Later sections assume the earlier ones. Resist the urge to jump straight to "Microservices."
2. Do the labs and projects — don't just read them Each section ends with a hands-on exercise on ShopSphere. DDD is a modeling skill, and modeling is learned by doing, getting it slightly wrong, and refining.
3. Take the section quizzes A short quiz closes every core section. Score 80% to mark it complete. They're designed to catch the subtle misunderstandings that derail real DDD projects.
4. Track your progress Your completed lessons are saved in this browser (look at the progress bar up top). Use "Mark as complete" at the bottom of each page.