God object & anemic domain model

A god object is a bloater at architecture scale — a single class that knows and does everything. A long method is a bloater inside one function; a god object is the same decay one level up: one class accumulates responsibilities until it becomes the centre of the system. Everything calls into it, so everything depends on it, so nothing can change without risking it.

class OrderService {
  createOrder() {/* ... */}
  validateInventory() {/* ... */}
  chargeCard() {/* ... */}
  calculateTax() {/* ... */}
  applyDiscount() {/* ... */}
  sendConfirmationEmail() {/* ... */}
  generateInvoicePdf() {/* ... */}
  scheduleShipment() {/* ... */}
  refund() {/* ... */}
  // ...60 more methods, 2,000 lines
}

The tell isn’t line count alone — it’s that the class has many unrelated reasons to change (tax law, payment provider, email template, PDF layout). It is a coupling singularity: a change to any one concern risks all the others, and every test must construct this whole universe to test a corner of it.

An anemic domain model is the opposite shape — data classes with no behaviour, and all logic in a separate procedural layer. Fowler named this: objects that are pure state — getters and setters — with the rules that govern that state living outside them, in “services”. It looks object-oriented (you have an Order class) but it is OO in name only: it’s procedural code with the data and the procedures pulled apart.

class Order {
  status: string;
  items: Item[];
  discountCents = 0;
  // ...only fields + get/set. No methods that mean anything.
}

// all real behaviour lives here, reaching INTO the data
class OrderService {
  applyDiscount(order: Order, pct: number) {
    if (order.status !== "open") throw new Error("closed");
    order.discountCents = Math.round(total(order.items) * pct);
  }
}

The cost: Order’s invariants (you can’t discount a closed order; a discount can’t exceed the total) are not protected by Order. Any code holding the object can set discountCents to nonsense. The data and the rules that keep it valid live in different files, so every reader has to assemble the real object in their head.

The cure is the same one principle: behaviour belongs with the data it operates on. Move the rule from the service into the entity, so the object enforces its own invariants. This is “tell, don’t ask” — instead of asking an order for its fields and deciding outside, you tell the order to do the thing and let it guard itself.

class Order {
  private status: "open" | "closed" = "open";
  private items: Item[];
  private discountCents = 0;

  applyDiscount(pct: number): void {
    if (this.status !== "open") throw new Error("cannot discount a closed order");
    if (pct < 0 || pct > 1) throw new Error("invalid discount");
    this.discountCents = Math.round(this.subtotal() * pct);
  }

  private subtotal(): number {
    return this.items.reduce((s, i) => s + i.priceCents * i.qty, 0);
  }
}

Now the invariant is unbreakable from outside: discountCents is private, and the only path to change it goes through a method that checks the rules. The rule lives next to the data it constrains, which is the whole point of an object. The procedural service shrinks; the model gets rich.

The trap: “fixing” anemia by cramming all logic into one entity recreates the god object. This is the failure mode that catches people who learned “rich model = good”. If every rule that mentions an order goes onto Order, then tax tables, payment gateways, PDF rendering, and shipment scheduling all migrate onto one class — and you have rebuilt OrderService, just spelled Order. You swapped an anemic data-bag plus a god service for a single god entity.

// OVERSHOOT — anemia "fixed" into a god entity
class Order {
  applyDiscount(pct: number) {/* belongs here ✓ */}
  chargeCard(gateway: PaymentGateway) {/* a payment concern ✗ */}
  renderInvoicePdf() {/* a presentation concern ✗ */}
  calculateTax(rates: TaxTable) {/* a tax-policy concern ✗ */}
}

The discriminator is cohesion, not “more methods on the entity”. Behaviour belongs with its data when it operates on that object’s own state and protects that object’s own invariants. applyDiscount reads and constrains the order’s items and status — it belongs. chargeCard orchestrates an external gateway; renderInvoicePdf is presentation; calculateTax is policy that varies independently. Those are different responsibilities and belong on different cohesive objects (a Money/Discount value object, a TaxPolicy, a PaymentGateway), not piled onto Order. The goal was never “fat entities” — it was behaviour distributed across many cohesive objects, each owning its own data.