Инверсия зависимостей

У DIP две половины, и про вторую все забывают. Принцип гласит: (а) высокоуровневые модули не должны зависеть от низкоуровневых — оба должны зависеть от абстракций; и (б) абстракции не должны зависеть от деталей — детали должны зависеть от абстракций. Большинство помнит половину (а) — «программируй на интерфейс» — и на этом останавливается. Половина (б) — вот что даёт DIP зубы: абстракция формируется тем, что нужно политике, а не тем, что случайно предлагает какой-то конкретный класс.

// high-level policy (stable: changes when the business changes)
class OrderService { /* what an order is, pricing, placement rules */ }

// low-level detail (volatile: changes when infra/vendors change)
class MySQLDatabase { /* connection pools, SQL, driver quirks */ }

Вопрос, на который отвечает DIP: в какую сторону идёт import между этими двумя?

Наивно стрелка указывает от политики к детали — и это баг. По умолчанию, то, что ты пишешь не задумываясь, — это когда высокоуровневый сервис напрямую делает import низкоуровневого драйвера. Теперь и зависимость времени компиляции, и зависимость времени выполнения текут от стабильного → к изменчивому.

import { MySQLDatabase } from "../infra/mysql";

class OrderService {
  private db = new MySQLDatabase();          // policy nailed to a vendor
  place(order: Order) {
    this.db.query("INSERT INTO orders ...");  // SQL leaking into business code
  }
}

Цена конкретна: ты не можешь юнит-тестировать place() без MySQL; переход на Postgres правит класс, который держит твои правила; а обновление драйвера может сломать бизнес-логику. Самый ценный код в системе — заложник наименее ценного. Именно это направление зависимости мы и хотим развернуть.

Инвертируй: определи интерфейс, который нужен политике, и которым владеет политика. Вместо OrderService → MySQLDatabase определи OrderRepository — интерфейс, сформулированный на языке домена (save(order), findById(id)), а не базы данных (query, exec). Сервис зависит от этого интерфейса. Конкретный MySqlOrderRepository реализует его. Критически важно: интерфейс живёт вместе с высокоуровневым модулем, в его пакете, как часть его контракта.

// owned by the policy layer — phrased in domain terms
export interface OrderRepository {
  save(order: Order): Promise<void>;
  findById(id: OrderId): Promise<Order | null>;
}

class OrderService {
  constructor(private orders: OrderRepository) {}   // depends on the abstraction
  async place(order: Order) {
    /* business rules */ await this.orders.save(order);
  }
}

Теперь и сервис, и драйвер зависят от OrderRepository. Стрелка от детали указывает вверх, на абстракцию политики. Именно это владение делает это «инверсией», а не просто «интерфейсом где-то».

Теперь деталь зависит от политики — стрелка действительно перевёрнута. MySqlOrderRepository импортирует OrderRepository (который принадлежит домену) и подстраивается под словарь домена. Зависимость времени компиляции идёт от инфраструктуры к домену. Изменчивая вещь зависит от стабильной вещи — а это то, что нужно, потому что стабильные вещи — хорошие цели для зависимостей.

import type { OrderRepository } from "../domain/OrderRepository";

export class MySqlOrderRepository implements OrderRepository {
  constructor(private db: MySQLDatabase) {}
  async save(order: Order) {
    await this.db.query("INSERT INTO orders ...", toRow(order));
  }
  async findById(id: OrderId) { /* SQL → Order */ }
}

// composition root wires the volatile detail into the stable policy
const service = new OrderService(new MySqlOrderRepository(mysql));

Тесты инжектят фейк; прод инжектит MySQL; миграция на Postgres — это один новый класс, реализующий тот же интерфейс, а OrderService не тронут. Тестируемость и заменяемость выпадают из перевёрнутой стрелки.