Not every Java type should be a rich object, but complex business behavior should not be hidden inside passive data either.

Why it matters in real Java systems

A checkout request DTO should usually be a data structure. An Order aggregate that owns payment and status rules should usually be an object. When teams confuse the two, they end up with anemic domain models, bloated services, or overengineered wrappers around simple transport data.

The design idea behind this topic

Java makes both styles easy. Records, DTOs, and response payloads are excellent data structures. Rich domain types are better when behavior and invariants matter.

The mistake is not using data structures. The mistake is using them at the center of a complex domain and then letting services carry all the business meaning. That is how an anemic domain model emerges.

Conversely, the mistake is also not turning every request and response shape into a rich object with methods it does not need. OOAD works best when the style matches the responsibility.

Key ideas to hold onto

Java example in the Order Management domain

package org.javaomnibus.ecommerce.foundations;

import java.util.List;

public record CheckoutRequest(String customerId, List items) {}
public record CheckoutItem(String sku, int quantity) {}

public final class Order {
    private final String customerId;
    private final List lines;
    private boolean submitted;

    public Order(String customerId, List lines) {
        this.customerId = customerId;
        this.lines = List.copyOf(lines);
    }

    public void submit() {
        if (lines.isEmpty()) {
            throw new IllegalStateException("An order must contain at least one line");
        }
        this.submitted = true;
    }

    public boolean isSubmitted() {
        return submitted;
    }
}

record OrderLine(String sku, int quantity) {}

Step by step

1. CheckoutRequest is a data structure. Its main job is carrying request data into the system.
2. Order is an object because it owns a business rule about submission.
3. The distinction keeps transport concerns and domain concerns from collapsing into one shape.
4. That separation also makes APIs, validation, and refactoring easier to reason about.

Where this shows up in practice

• REST and messaging boundaries where DTOs enter and leave the system
• Domain models that need to protect business transitions or invariants
• Systems that need a cleaner boundary between transport, application flow, and domain behavior

When not to over-apply it

Rich objects require thoughtful modeling. DTOs are faster to create. The right choice depends on where the complexity lives and whether the type is central to business behavior or mainly a boundary shape.

Frequent mistakes to watch for

• Treating every domain concept as a DTO with setters
• Adding domain logic to request or response payloads just to avoid more types
• Wrapping trivial transport structures in unnecessary behavior
• Forgetting that records can still be useful for some immutable value-oriented domain concepts

Related concepts