Anemic vs rich domain model

What an anemic domain model looks like

Martin Fowler coined the term “Anemic Domain Model” in 2003 to describe a pattern that had become pervasive: domain objects that are little more than named data structures — getters, setters, and no real behavior — combined with service classes that contain all the logic.

// Anemic: Order is a data bag
class Order {
  id: string;
  status: string;
  lineItems: LineItem[];
  totalAmount: number;
  customerId: string;
  approvedBy?: string;
  approvedAt?: Date;

  // Only getters and setters — no behavior, no enforcement
  setStatus(s: string) { this.status = s; }
  setApprovedBy(userId: string) { this.approvedBy = userId; }
}

// All logic in the service
class OrderService {
  async confirmOrder(orderId: string, userId: string) {
    const order = await this.repo.findById(orderId);
    if (order.status === 'pending') {
      order.setStatus('confirmed');
      order.setApprovedBy(userId);
      order.approvedAt = new Date();
      await this.repo.save(order);
    }
  }
}

The service knows the rules. The order object enforces nothing. Any code anywhere can call order.setStatus('confirmed') directly, bypassing every check in OrderService. The invariant “only pending orders can be confirmed” exists only inside one method of one service class.

Fowler’s verdict: this is an anti-pattern because it defeats the purpose of object-oriented design. An object that owns no behavior and enforces no invariants is not a domain model — it is a glorified C struct with Java syntax.

Why it becomes a problem — with complex invariants

The anemic model’s rot appears gradually, and it appears specifically when invariants become complex or multiple.

In the B2B order platform, the rules governing an order’s lifecycle multiplied over time:

• A pending order can be confirmed only if it has at least one line item.
• An order above $10,000 requires approval before confirmation.
• A confirmed order can be cancelled only within 24 hours.
• A cancelled order cannot be invoiced, confirmed, or re-opened.
• An order’s total amount must equal the sum of its line items at all times.

Each of these rules was implemented inside a different service method. confirmOrder checked two of them. cancelOrder checked one. The billing job checked none — it had been written by a different team that did not know the order lifecycle rules. The bug was not a programming mistake — it was a structural mistake. The rules were scattered across service methods that had no guarantee of being the only code path that could mutate the order.

Encapsulation is the core property the anemic model destroys. Encapsulation is not about hiding fields behind getter/setter method calls — that is just syntactic wrapping. Real encapsulation means that an object’s internal state can only be changed through operations that enforce the object’s invariants. If any external code can call setStatus('confirmed') directly, the Order object provides no encapsulation regardless of whether status is private.

The rich domain model alternative

A rich domain model places behavior with the data it governs. The Order object owns its state transitions and enforces its invariants at the boundary of each operation:

// Rich: Order owns its invariants
class Order {
  private status: OrderStatus;
  private lineItems: LineItem[];
  private totalAmount: Money;
  private approvalRecord?: ApprovalRecord;

  confirm(approvedBy: UserId): void {
    if (this.status !== OrderStatus.Pending) {
      throw new InvalidOrderTransitionError(
        `Cannot confirm an order in status ${this.status}`
      );
    }
    if (this.lineItems.length === 0) {
      throw new OrderInvariantViolation('Cannot confirm an order with no line items');
    }
    if (this.totalAmount.greaterThan(Money.of(10_000, 'USD')) && !this.approvalRecord) {
      throw new OrderInvariantViolation('Orders above $10,000 require prior approval');
    }
    this.status = OrderStatus.Confirmed;
    this.confirmedAt = new Date();
  }

  cancel(): void {
    if (this.status === OrderStatus.Cancelled) {
      throw new InvalidOrderTransitionError('Order already cancelled');
    }
    this.status = OrderStatus.Cancelled;
    this.cancelledAt = new Date();
  }
}

Now the BillingJob cannot set status = 'confirmed' directly — it must call order.confirm(), which enforces every relevant rule. The billing bug from the opening story becomes impossible: calling confirm() on a cancelled order throws an error. No second caller can bypass it.

The honest counter-case: when anemic is fine

Fowler’s critique is correct for complex domains with meaningful invariants. It is NOT a universal law. The anemic model is perfectly appropriate when:

The domain is genuinely CRUD. A user profile management service — create, read, update, delete user records — has no state machine, no multi-step lifecycle, no invariants beyond “email must be unique.” A rich domain model here adds indirection and boilerplate with no return. An anemic model is honest about what the domain is.

The domain is simple and stable. Configuration tables, lookup tables, reference data — this is data management, not domain modeling. ORM entities with getters and setters are the right fit.

The application is short-lived or throwaway. A data migration script, a one-time ETL job, an internal admin panel used by three people — the cost of establishing a rich domain model is not justified by the return.

The anti-pattern label applies when a team uses an anemic model for a complex domain with meaningful lifecycle invariants — and then experiences the consequences (invariant violations, scattered logic, inability to reason about state) while insisting it was the right choice. The problem is not anemic-vs-rich as a religious question. The problem is using the wrong tool for the domain’s actual complexity.