Domain-Driven Design

Domain-Driven Design

Aggregate Rules

• One repository per aggregate root
• External code only accesses aggregate through root — never child entities directly
• Prefer references by ID across aggregate boundaries; preserve deliberate mappings.
• Choose boundaries from invariants that must commit atomically and expected contention, not a fixed number of child entities. Splitting requires an explicit consistency plan.

The snippets are illustrative and require the application's domain types and imports. Keep existing public identifiers and persistence mappings unless the task includes a migration.

// ✅ Aggregate root controls all access to children
order.addItem(productId, quantity); // through root
order.removeItem(itemId);           // through root

// ❌ Direct child access from outside
order.getItems().add(new OrderItem(...)); // bypasses invariants

Value Objects

Immutable, no identity, equality by value:

public record Money(BigDecimal amount, Currency currency) {
    public Money {
        if (amount.compareTo(BigDecimal.ZERO) < 0)
            throw new IllegalArgumentException("Amount cannot be negative");
        Objects.requireNonNull(currency);
    }

    public Money add(Money other) {
        if (!currency.equals(other.currency))
            throw new CurrencyMismatchException(currency, other.currency);
        return new Money(amount.add(other.amount), currency);
    }

    public static Money of(String amount, String currency) {