Domain Model Pattern

Also Known As

TL;DR

Explanation

The Domain Model pattern (Martin Fowler, PoEAA) puts business logic inside the domain objects themselves. Unlike Anemic Domain Model (data containers with no behaviour) or Transaction Script (logic in service layer), a rich domain model has Order::place(), Invoice::generate(), and User::grantPermission() — the objects do things. This aligns with DDD aggregates and is the foundation for DDD tactical patterns. Best for: complex business logic with many rules and invariants. Overkill for: simple CRUD with few rules.

Common Misconception

Why It Matters

Common Mistakes

• Domain model extending ORM base class — couples domain to persistence, prevents pure unit testing.
• Getters and setters on all fields — allows external code to put the object in invalid state.
• Domain methods that take primitive arguments instead of value objects — Order::apply(42) vs Order::apply(new Discount(42, 'percent')).
• Logic that crosses aggregate boundaries in a single method — use domain events instead.

Code Examples

// Anemic model — no behaviour:
class Order {
    public int $status;
    public float $total;
    // No methods — just data
}

// Logic in service — scattered:
class OrderService {
    public function ship(Order $order): void {
        $order->status = 3; // Magic number
        $order->shipped_at = now(); // Direct mutation
    }
}

// Rich domain model — behaviour in the object:
class Order {
    private OrderStatus $status;
    private Money $total;

    public function ship(TrackingNumber $tracking): void {
        if (!$this->status->canBeShipped()) {
            throw new InvalidOrderTransition('Order cannot be shipped from ' . $this->status);
        }
        $this->status = OrderStatus::Shipped;
        $this->trackingNumber = $tracking;
        $this->raise(new OrderShipped($this->id, $tracking));
    }
}

References

• ↗ https://www.martinfowler.com/eaaCatalog/domainModel.html

Tags

Related Terms