Domain-Driven Design — modelování komplexních domén

Jak rozdělit monolit na mikroslužby? Podle tabulek? Podle UI stránek? Špatně. Podle business domén. Domain-Driven Design od Erica Evanse dává framework pro modelování komplexních systémů — a bounded contexts jsou ideální hranice pro mikroslužby.

Bounded Context¶

Bounded context je explicitní hranice, kde doménový model platí. „Zákazník” v CRM je jiný než „Zákazník” ve fakturaci. Stejné slovo, jiný kontext, jiný model. Každý bounded context = kandidát na mikroslužbu.

Ubiquitous Language¶

DDD vyžaduje společný jazyk mezi vývojáři a business experty. Když business říká „objednávka”, kód má třídu Order, ne TransactionRecord. Jazyk kódu = jazyk domény. Žádné překlady.

Aggregáty a entity¶

Entity: Objekty s identitou (Order, Customer). Lifecycle, změny stavu. Value Object: Objekty bez identity (Money, Address). Immutable. Aggregate: Cluster objektů s kořenovou entitou. Transakční hranice. Pravidlo: modifikace jen přes 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¶

Jak spolu bounded contexts komunikují? Shared Kernel (sdílený model), Customer-Supplier (upstream/downstream), Anti-Corruption Layer (překlad mezi modely). Pro mikroslužby typicky ACL — každá služba chrání svůj model.

DDD je investice, která se vrátí¶

DDD není pro každý projekt — pro CRUD aplikace je overkill. Ale pro komplexní doménovou logiku a správné rozdělení mikroslužeb je neocenitelný.