Domain-Driven Design

A big ball of mud, and everyone speaks a different language

Business rules leak into controllers and SQL scripts. The model itself is just data — getters and setters, no behavior. And "cart", "order", "purchase" all mean the same thing to three different people.

// rule buried in a controller, not the domain
class OrderController {
  checkout(req) {
    if (req.total > 1000) req.discount = 0.1;
    db.update('orders', req.id, { total: req.total });
  }
}
// the "model" is anemic — just fields
class Order { getTotal(){} setTotal(t){} }

Model the domain, speak the experts' language

Code and domain experts share one Ubiquitous Language. Complex domains split into Bounded Contexts; each has its own valid model.

class Order {  // Entity — has identity
  addLineItem(sku, qty, price) { /* enforces rules */ }
  confirm() { /* locks the order */ }
}
class Money {  // Value Object — equal by value
  constructor(amount, ccy) { ... }
}

The aggregate root enforces its own rules

The Order aggregate — not a controller — decides what's allowed: total capped at $1000, and no edits once confirmed.

Model the domain, not the database

• Ubiquitous Language: code and domain experts use the exact same words.
• Model the domain, not a table — behavior lives on entities, not controllers.
• Aggregates guard invariants: the root is the only door in; it rejects invalid changes.
• Split by Bounded Context: each context gets its own model — no single "god" schema.
• Caution: DDD is heavyweight. Reserve it for complex core domains — plain CRUD doesn't need it (YAGNI).