Как можно разделять исключения по смыслу и доменной логике, используя функциональный подход?

В функциональном программировании исключения считаются побочным эффектом: они не видны в сигнатуре функции и легко забываются. Вместо этого ошибку возвращают как обычное значение, чаще всего через алгебраический тип Result<T, E> или Either<E, T>. Это позволяет явно разделять ошибки по смыслу: доменные (например, InsufficientFunds) и технические (например, DatabaseUnavailable) становятся разными вариантами одного типа.

Доменные ошибки как данные

Доменная ошибка описывает нарушение бизнес-правила и является частью языка предметной области. Её удобно моделировать отдельным типом или union-типом:

type DomainError =
  | { kind: 'InsufficientFunds'; balance: number }
  | { kind: 'AccountBlocked'; reason: string }
  | { kind: 'LimitExceeded'; limit: number };

type Result<T, E> =
  | { ok: true; value: T }
  | { ok: false; error: E };

function withdraw(balance: number, amount: number): Result<number, DomainError> {
  if (balance < amount) return { ok: false, error: { kind: 'InsufficientFunds', balance } };
  return { ok: true, value: balance - amount };
}

Разделение слоёв ошибок

Технические сбои (таймауты, отказ БД) обычно не являются частью домена. Их можно оставлять исключениями на границе приложения и преобразовывать в Result только там, где это нужно бизнес-логике. Так доменный код остаётся чистым, а инфраструктурные детали не протекают внутрь.

• Доменные ошибки — типизированные значения, обрабатываются явно.
• Технические ошибки — исключения или отдельный тип InfraError.
• На границе (HTTP, CLI) ошибки маппятся в коды ответов.

Композиция и обработка

Функции map и flatMap позволяют строить цепочки без проверок if (err) return err на каждом шаге. Это делает код линейным и читаемым:

const result = withdraw(balance, amount)
  .flatMap(newBalance => chargeFee(newBalance, fee))
  .map(finalBalance => ({ balance: finalBalance }));

if (!result.ok) {
  switch (result.error.kind) {
    case 'InsufficientFunds': return http400(result.error);
    case 'AccountBlocked': return http403(result.error);
  }
}

Итог: функциональный подход к ошибкам стоит применять там, где важна предсказуемость и явное разделение доменных и технических сбоев — например, в финансовых системах, парсерах, бизнес-правилах. Это делает контракты функций честными, а обработку ошибок — частью типовой системы.