Domain-Driven Design and Functional Programming: Allies or Rivals?

Ask two experienced developers whether domain-driven design and functional programming belong together and you will often get a puzzled look. DDD, as it is usually taught, is an object-oriented discipline: rich entities with behavior, aggregates that guard invariants, repositories, services, a hexagon of ports and adapters. Functional programming pulls the other way: immutable data, pure functions, side effects pushed to the edges, behavior expressed as transformations rather than methods hanging off objects.

So which is it — allies or rivals?

The short answer is allies, and not by coincidence. The strategic patterns of DDD (ubiquitous language, bounded contexts, context maps) are about communication and boundaries; they are paradigm-agnostic and apply just as well to functional code. The tactical patterns (value objects, entities, aggregates, domain events) turn out to describe exactly the things functional programming is best at. The friction is not in the ideas. It is in the accidental object-oriented packaging those ideas are usually delivered in.

Let us walk the tactical patterns one by one.

Value objects are already functional

A value object has no identity. It is defined entirely by its attributes, it is immutable, and two value objects with the same attributes are equal and interchangeable. Money, EmailAddress, DateRange, Quantity — these are the vocabulary of the domain.

Read that definition again. Immutable, equality by value, no identity. That is the definition of a functional value. There is nothing to reconcile here — a value object is an algebraic value. In modern Java a record expresses it directly:

public record Money(BigDecimal amount, Currency currency) {
    public Money {
        requireNonNull(amount, "amount");
        requireNonNull(currency, "currency");
    }

    public Money plus(Money other) {
        if (!currency.equals(other.currency)) {
            throw new IllegalArgumentException("currency mismatch");
        }
        return new Money(amount.add(other.amount), currency);   // returns a new value
    }
}

plus does not mutate. It returns a new Money. This is how DDD always described value objects — “operations return new instances” — and it is also the first rule of functional programming. The patterns agree completely.

Making illegal states unrepresentable

DDD tells you to protect invariants: a value object should be impossible to construct in an invalid state. Functional programming says the same thing with a different slogan — make illegal states unrepresentable — and hands you sharper tools to do it.

The naive constructor throws. That works, but it means construction is a side-channel: the caller has to know that new EmailAddress(raw) might blow up, and a validation failure becomes an exception to catch rather than a value to handle. A functional smart constructor returns the outcome as a value instead:

public record EmailAddress(String value) {
    public static Result<EmailAddress, String> of(String raw) {
        if (raw == null || !raw.contains("@")) {
            return Result.err("invalid email address: " + raw);
        }
        return Result.ok(new EmailAddress(raw));
    }
}

Now “this string might not be a valid email” is visible in the type. The domain rule is enforced at the boundary, and every caller is forced by the compiler to decide what to do when it fails. The invariant DDD asked for is still there — it just stopped hiding in a throws clause.

When a value object has to satisfy several rules at once, throwing on the first failure is a poor user experience. This is where Validated earns its place: it accumulates all the violations instead of stopping at the first.

static Validated<NonEmptyList<String>, Customer> validate(SignupForm form) {
    return Validated.combine3(
        validateName(form.name()),
        validateEmail(form.email()),
        validateAge(form.age()),
        NonEmptyList::concat,     // how to merge errors when more than one fails
        Customer::new);           // Valid(Customer) only if all three pass
}

A DDD purist and an FP purist would both nod at this: the aggregate is only constructed when every invariant holds, and the caller gets a complete list of what was wrong when it does not.

Entities and aggregates: identity without mutation

This is where the paradigms appear to diverge. Entities have identity and a lifecycle; an aggregate changes state over time. Surely that requires mutation?

It requires change, not mutation. Functional programming models a changing entity as a sequence of immutable snapshots: each command produces a new version of the aggregate rather than editing the old one in place.

public record Order(OrderId id, OrderStatus status, List<LineItem> items) {

    public Result<Order, OrderError> confirm() {
        if (status != OrderStatus.PENDING) {
            return Result.err(new OrderError.NotPending(status));
        }
        if (items.isEmpty()) {
            return Result.err(new OrderError.Empty());
        }
        return Result.ok(new Order(id, OrderStatus.CONFIRMED, items));
    }
}

confirm() is a pure function of the aggregate: same order in, same result out, no hidden state, no surprises. The identity (OrderId) is preserved across versions, exactly as DDD requires. The consistency boundary is preserved too — the method is the only door through which the transition can happen, and it refuses to open when the invariant would be broken. What changed is that the business rule violation is a typed value (OrderError) rather than a thrown exception, so it composes with everything downstream.

The aggregate is still the unit of consistency. It just became a value that transitions instead of an object that mutates.

Domain events are algebraic data types

DDD models significant occurrences as domain events: OrderConfirmed, PaymentCaptured, ShipmentDispatched. A well-modeled event stream is a closed set of possibilities — precisely an algebraic data type. Sealed interfaces and records express it, and pattern matching consumes it exhaustively:

sealed interface OrderEvent {
    record Confirmed(OrderId id, Instant at) implements OrderEvent {}
    record Cancelled(OrderId id, String reason) implements OrderEvent {}
    record Shipped(OrderId id, String trackingCode) implements OrderEvent {}
}

String describe(OrderEvent event) {
    return switch (event) {                       // compiler enforces every case
        case OrderEvent.Confirmed c  -> "confirmed at " + c.at();
        case OrderEvent.Cancelled x  -> "cancelled: " + x.reason();
        case OrderEvent.Shipped s    -> "shipped via " + s.trackingCode();
    };
}

Add a new event tomorrow and every non-exhaustive switch becomes a compile error pointing you at the code that needs updating. The domain model stops living in a wiki and starts living in the type system — which is what DDD wanted all along.

Repositories, absence, and typed failure

DDD repositories abstract persistence behind a collection-like interface. The classic Java signature — Order findById(OrderId id) — has two well-known lies baked in: it returns null when nothing is found, and it throws when the database misbehaves. Both are invisible in the type.

Functional types make the honest signature the natural one:

interface OrderRepository {
    Option<Order> findById(OrderId id);                    // absence is explicit
    Result<Order, PersistenceError> save(Order order);     // failure is a value
}

“There might be no such order” and “saving can fail” are now part of the contract the compiler enforces. The application service that orchestrates the use case reads as a pipeline of these outcomes:

Result<Order, OrderError> confirmOrder(OrderId id) {
    return orders.findById(id)
        .toResult(new OrderError.NotFound(id))          // Option -> Result
        .flatMap(Order::confirm)                        // aggregate transition
        .flatMap(order -> orders.save(order)
            .mapError(OrderError::persistence));
}

There is no try/catch, no null check, no early-return ladder. The happy path is the main line; every failure is a typed detour the compiler made you account for. This is a textbook DDD application service — load the aggregate, invoke a domain method, persist — expressed as function composition.

Where the tension is real

None of this means the fit is frictionless. Two honest points of contact:

Side effects and purity. Persistence, messaging, and time are effects, and a domain aggregate should not perform them. DDD’s answer is repositories and application services; FP’s answer is pushing effects to the edges. These are the same answer — keep the aggregate pure, orchestrate effects around it — but it takes discipline to hold the line, especially when a framework makes it easy to inject a repository straight into an entity.
Rich objects vs. data + functions. Classic DDD hangs behavior off entities as methods. Functional style often prefers plain data with transformations applied from the outside. Both work; the record-with-methods hybrid above is a comfortable middle ground for Java, keeping the method discoverable on the type while the body stays pure.

These are trade-offs to navigate, not contradictions to resolve. The strategic core of DDD — model the domain in the language of the business, guard your boundaries — is entirely neutral on paradigm.

Allies

Domain-driven design tells you what to model: the invariants, the boundaries, the events, the ubiquitous language. Functional programming gives you the tools to make those models precise: value objects as immutable records, invariants as smart constructors returning Result or Validated, lifecycles as pure transitions, events as sealed hierarchies, repositories that tell the truth about absence and failure.

They were never really rivals. DDD is a set of questions about the domain; FP is a set of sharp answers about how to encode them so the compiler helps you keep them true. Used together, the domain model stops being documentation you hope the code matches — and becomes the code.

The dmx-fun library gives you the building blocks — Option, Result, Validated, NonEmptyList, and the rest — to model your domain this way in plain Java. The Developer Guide walks through each type with examples.