Anemic vs rich domain model

Как выглядит anemic domain model

Мартин Фаулер ввёл термин «Anemic Domain Model» в 2003 году для описания паттерна, ставшего повсеместным: доменные объекты — не более чем именованные структуры данных (геттеры, сеттеры, никакого реального поведения) — в сочетании с классами-сервисами, содержащими всю логику.

// Anemic: Order — пакет данных
class Order {
  id: string;
  status: string;
  lineItems: LineItem[];
  totalAmount: number;
  customerId: string;
  approvedBy?: string;
  approvedAt?: Date;

  // Только геттеры и сеттеры — никакого поведения, никакого применения правил
  setStatus(s: string) { this.status = s; }
  setApprovedBy(userId: string) { this.approvedBy = userId; }
}

// Вся логика в сервисе
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);
    }
  }
}

Сервис знает правила. Объект Order ничего не применяет. Любой код в системе может вызвать order.setStatus('confirmed') напрямую, обойдя все проверки в OrderService. Инвариант «только pending-заказы можно подтвердить» существует только внутри одного метода одного класса-сервиса.

Вердикт Фаулера: это антипаттерн, потому что он лишает смысла объектно-ориентированный дизайн. Объект, не владеющий никаким поведением и не применяющий никаких инвариантов — это не доменная модель, а struct из C с синтаксисом Java.

Почему это становится проблемой — при сложных инвариантах

Деградация anemic-модели появляется постепенно, и именно тогда, когда инварианты становятся сложными или множественными.

На B2B-платформе правила, управляющие жизненным циклом заказа, со временем умножились:

• Pending-заказ можно подтвердить только если у него есть хотя бы одна позиция.
• Заказ на сумму свыше $10 000 требует одобрения перед подтверждением.
• Подтверждённый заказ можно отменить только в течение 24 часов.
• Отменённый заказ нельзя выставить на счёт, подтвердить или переоткрыть.
• Итоговая сумма заказа всегда должна равняться сумме его позиций.

Каждое из этих правил было реализовано внутри отдельного метода сервиса. confirmOrder проверял два из них. cancelOrder — одно. Billing-задание — ни одного: оно было написано другой командой, не знавшей о правилах жизненного цикла заказа. Баг был не ошибкой программирования — это была структурная ошибка. Правила были разбросаны по методам сервиса без гарантии быть единственным путём мутации заказа.

Инкапсуляция — это ключевое свойство, которое anemic-модель уничтожает. Инкапсуляция — это не сокрытие полей за геттером/сеттером: это просто синтаксическая обёртка. Настоящая инкапсуляция означает, что внутреннее состояние объекта может изменяться только через операции, применяющие инварианты объекта. Если любой внешний код может вызвать setStatus('confirmed') напрямую, объект Order не даёт никакой инкапсуляции, независимо от того, является ли поле status приватным.

Rich domain model как альтернатива

Rich domain model помещает поведение вместе с данными, которыми оно управляет. Объект Order владеет своими переходами состояний и применяет инварианты на границе каждой операции:

// Rich: Order владеет своими инвариантами
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(
        `Нельзя подтвердить заказ в статусе ${this.status}`
      );
    }
    if (this.lineItems.length === 0) {
      throw new OrderInvariantViolation('Нельзя подтвердить заказ без позиций');
    }
    if (this.totalAmount.greaterThan(Money.of(10_000, 'USD')) && !this.approvalRecord) {
      throw new OrderInvariantViolation('Заказы свыше $10 000 требуют предварительного одобрения');
    }
    this.status = OrderStatus.Confirmed;
    this.confirmedAt = new Date();
  }

  cancel(): void {
    if (this.status === OrderStatus.Cancelled) {
      throw new InvalidOrderTransitionError('Заказ уже отменён');
    }
    this.status = OrderStatus.Cancelled;
    this.cancelledAt = new Date();
  }
}

Теперь BillingJob не может установить status = 'confirmed' напрямую — он должен вызвать order.confirm(), которая применяет каждое соответствующее правило. Баг из вступительной истории становится невозможным: вызов confirm() на отменённом заказе выбросит ошибку. Ни один второй вызывающий не может обойти это.

Честный контраргумент: когда anemic подходит

Критика Фаулера верна для сложных доменов со значимыми инвариантами. Это НЕ универсальный закон. Anemic-модель вполне уместна когда:

Домен — действительно CRUD. Сервис управления профилями пользователей — создать, прочитать, обновить, удалить записи — не имеет state machine, многоэтапного жизненного цикла, инвариантов сложнее «email должен быть уникальным». Rich domain model здесь добавит косвенность и boilerplate без отдачи. Anemic-модель честна в том, что собой представляет домен.

Домен прост и стабилен. Таблицы конфигурации, справочники, референсные данные — это управление данными, а не доменное моделирование. ORM-сущности с геттерами и сеттерами — правильный инструмент.

Приложение краткосрочное или одноразовое. Скрипт миграции данных, одноразовый ETL-job, внутренняя admin-панель для трёх пользователей — стоимость создания rich domain model не оправдана отдачей.

Метка антипаттерна применяется, когда команда использует anemic-модель для сложного домена со значимыми инвариантами жизненного цикла — и затем испытывает последствия (нарушения инвариантов, разбросанная логика, невозможность рассуждать о состоянии), настаивая, что сделала правильный выбор. Проблема — не религиозный вопрос anemic vs rich. Проблема — использование неправильного инструмента для реальной сложности домена.