Божественный объект и анемичная доменная модель

Божественный объект — это разбухание на масштабе архитектуры: единственный класс, который знает и делает всё. Длинный метод — это разбухание внутри одной функции; божественный объект — та же деградация уровнем выше: один класс накапливает обязанности, пока не становится центром системы. Всё обращается к нему, значит всё зависит от него, значит ничего нельзя изменить, не рискнув им.

class OrderService {
  createOrder() {/* ... */}
  validateInventory() {/* ... */}
  chargeCard() {/* ... */}
  calculateTax() {/* ... */}
  applyDiscount() {/* ... */}
  sendConfirmationEmail() {/* ... */}
  generateInvoicePdf() {/* ... */}
  scheduleShipment() {/* ... */}
  refund() {/* ... */}
  // ...ещё 60 методов, 2000 строк
}

Маркер — не одно лишь число строк, а то, что у класса много несвязанных причин для изменения (налоговое право, платёжный провайдер, шаблон письма, вёрстка PDF). Это сингулярность связанности: изменение в любой одной заботе рискует всеми остальными, и каждому тесту приходится строить всю эту вселенную, чтобы протестировать её уголок.

Анемичная доменная модель — противоположная форма: классы-данные без поведения, и вся логика — в отдельном процедурном слое. Фаулер дал этому имя: объекты, которые суть чистое состояние — геттеры и сеттеры, — а правила, управляющие этим состоянием, живут вне их, в «сервисах». Выглядит объектно-ориентированно (у тебя есть класс Order), но это ООП только по названию: это процедурный код, у которого данные и процедуры растащены по сторонам.

class Order {
  status: string;
  items: Item[];
  discountCents = 0;
  // ...только поля + get/set. Ни одного метода, что-либо значащего.
}

// всё настоящее поведение живёт здесь, дотягиваясь ВНУТРЬ данных
class OrderService {
  applyDiscount(order: Order, pct: number) {
    if (order.status !== "open") throw new Error("closed");
    order.discountCents = Math.round(total(order.items) * pct);
  }
}

Цена: инварианты Order (нельзя скидывать закрытый заказ; скидка не может превышать сумму) защищены не самим Order. Любой код, держащий объект, может выставить discountCents в бессмыслицу. Данные и правила, что держат их валидными, живут в разных файлах, поэтому каждому читателю приходится собирать настоящий объект у себя в голове.

Лекарство — один и тот же принцип: поведение принадлежит данным, над которыми оно работает. Перенеси правило из сервиса внутрь сущности, чтобы объект сам обеспечивал свои инварианты. Это «говори, не спрашивай»: вместо того чтобы спрашивать у заказа его поля и решать снаружи, ты говоришь заказу сделать дело и даёшь ему охранять самого себя.

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);
  }
}

Теперь инвариант снаружи нерушим: discountCents приватен, и единственный путь его изменить идёт через метод, который проверяет правила. Правило живёт рядом с данными, которые оно ограничивает, — а в этом и весь смысл объекта. Процедурный сервис ужимается; модель становится богатой.

Ловушка: «починка» анемии путём впихивания всей логики в одну сущность воссоздаёт божественный объект. Это режим отказа, который ловит тех, кто выучил «богатая модель = хорошо». Если каждое правило, упоминающее заказ, отправляется в Order, то налоговые таблицы, платёжные шлюзы, рендеринг PDF и планирование отгрузки — все мигрируют в один класс, и ты заново собрал OrderService, только записанный как Order. Ты поменял анемичный мешок-данные плюс божественный сервис на единственную божественную сущность.

// ПЕРЕЛЁТ — анемия «починена» в божественную сущность
class Order {
  applyDiscount(pct: number) {/* здесь и место ✓ */}
  chargeCard(gateway: PaymentGateway) {/* забота платежей ✗ */}
  renderInvoicePdf() {/* забота представления ✗ */}
  calculateTax(rates: TaxTable) {/* забота налоговой политики ✗ */}
}

Различитель — связность, а не «больше методов на сущности». Поведение принадлежит своим данным, когда оно работает над собственным состоянием этого объекта и защищает его собственные инварианты. applyDiscount читает и ограничивает позиции и статус заказа — оно здесь к месту. chargeCard оркестрирует внешний шлюз; renderInvoicePdf — это представление; calculateTax — политика, которая меняется независимо. Это разные обязанности, и они принадлежат разным связным объектам (объекту-значению Money/Discount, TaxPolicy, PaymentGateway), а не свалены в Order. Целью никогда не были «жирные сущности» — целью было поведение, распределённое по множеству связных объектов, каждый из которых владеет своими данными.