/domain-driven-design

name: domain-driven-design
description: >
  Use when evolving aggregate invariants, value objects or domain events in an existing
  DDD-style Spring Boot 3 application, or when DDD is explicitly requested. Preserve existing
  API identifiers and architecture when changing domain behavior.

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.

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

// BAD: 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) {
        return new Money(new BigDecimal(amount), Currency.getInstance(currency));
    }
}

public record EmailAddress(String value) {
    public EmailAddress {
        if (!value.matches("^[\\w.-]+@[\\w.-]+\\.[a-z]{2,}$"))
            throw new InvalidEmailException(value);
    }
}

Domain Events

// Event — immutable record
public record OrderPlaced(OrderId orderId, CustomerId customerId, Money total, Instant occurredAt) {
    public static OrderPlaced of(Order order) {
        return new OrderPlaced(order.getId(), order.getCustomerId(), order.getTotal(), Instant.now());
    }
}

// Collect events in aggregate, publish after save
@Entity
public class Order {
    @Transient
    private final List<Object> domainEvents = new ArrayList<>();

    public void place() {
        this.status = OrderStatus.PLACED;
        domainEvents.add(OrderPlaced.of(this));
    }

    public List<Object> pullDomainEvents() {
        var events = List.copyOf(domainEvents);
        domainEvents.clear();
        return events;
    }
}

// Publish inside the transaction; save() is not commit.
@Service
@RequiredArgsConstructor
public class OrderApplicationService {
    private final OrderRepository orderRepository;
    private final ApplicationEventPublisher eventPublisher;

    @Transactional
    public Order placeOrder(PlaceOrderCommand command) {
        Order order = orderRepository.findById(command.orderId()).orElseThrow();
        order.place();
        Order saved = orderRepository.save(order);
        saved.pullDomainEvents().forEach(eventPublisher::publishEvent); // commit-bound listener below
        return saved;
    }
}

// Listen to events — bind to commit, not just publish.
// @EventListener fires synchronously inside the TX; if the TX later rolls back you've
// already sent the email. AFTER_COMMIT avoids rollback delivery but is best effort.
@Component
@RequiredArgsConstructor
public class OrderPlacedHandler {
    private final EmailService emailService;

    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void onOrderPlaced(OrderPlaced event) {
        emailService.sendOrderConfirmation(event.customerId(), event.orderId());
    }
}

> **Let Spring Data publish for you.** Instead of calling `pullDomainEvents()` by hand, expose a > `@DomainEvents` method (returns the collected events) and an `@AfterDomainEventPublication` method > (clears them) on the aggregate root. Spring Data's repository drains and publishes them automatically > on every `save()` — no manual wiring in the service.

Neither publication mechanism guarantees durable delivery. For required external effects, persist an outbox entry with the aggregate change or use a persistent publication registry, with idempotent consumers and retry/recovery. `@Async` changes execution, not durability. Post-commit database writes need a new transaction because the original resources may still be bound after completion. See [transaction boundaries](../transactional-patterns/SKILL.md), [messaging](../event-driven-messaging/SKILL.md) and [Modulith](../spring-modulith/SKILL.md).

Specifications (complex queries)

public class OrderSpecifications {
    public static Specification<Order> byStatus(OrderStatus status) {
        return (root, query, cb) -> cb.equal(root.get("status"), status);
    }

    public static Specification<Order> byCustomer(UUID customerId) {
        return (root, query, cb) -> cb.equal(root.get("customerId"), customerId);
    }

    public static Specification<Order> placedAfter(Instant date) {
        return (root, query, cb) -> cb.greaterThan(root.get("placedAt"), date);
    }
}

// Compose
Specification<Order> spec = OrderSpecifications.byStatus(PLACED)
    .and(OrderSpecifications.byCustomer(customerId))
    .and(OrderSpecifications.placedAfter(lastWeek));

orderRepository.findAll(spec, pageable);

Anti-Corruption Layer (ACL)

• When integrating with external systems or legacy code, don't let their models leak into your domain
• Create an ACL — a translation layer that converts external data to your domain language
• ACL lives in infrastructure layer, not domain

// GOOD — ACL translates