Что такое бизнес-логика

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

Для frontend-разработчика важна не только формулировка, но и граница ответственности. Frontend часто помогает пользователю пройти сценарий правильно, но не должен быть единственным местом, где защищены важные правила.

Допустим, в магазине кнопку оформления заказа нужно показывать только если корзина не пустая, товары доступны, профиль подтвержден и нет конфликта с лимитом заказа. Плохой вариант - размазать это условие по разным компонентам.

// Плохо: правило спрятано в JSX и его легко скопировать с ошибкой
{cart.items.length > 0 && user.isVerified && !cart.hasUnavailableItems && (
  <button onClick={submitOrder}>Оформить заказ</button>
)}

Лучше дать правилу имя. Тогда его проще обсудить с командой, переиспользовать и протестировать.

export function canSubmitOrder(cart: Cart, user: User) {
  return (
    cart.items.length > 0 &&
    user.isVerified &&
    !cart.hasUnavailableItems &&
    cart.total <= cart.limit
  );
}

const canSubmit = canSubmitOrder(cart, user);

return (
  <button disabled={!canSubmit} onClick={submitOrder}>
    Оформить заказ
  </button>
);

Важно: даже такой код не заменяет серверную проверку. Он только делает интерфейс понятнее и уменьшает число заведомо неверных действий.

На интервью хорошо показать, что вы не мыслите крайностями. Не нужно говорить, что вся бизнес-логика живет только на backend или только на frontend. Правильнее говорить про источник истины и цель конкретного правила.

Если правило влияет на безопасность, деньги или права, сервер должен подтвердить его всегда. Если правило помогает пользователю не ошибиться в форме, frontend может проверить его раньше и показать понятное сообщение. Если правило повторяется, его стоит вынести из компонента.

Хороший ответ можно построить в три шага.

1. Дайте определение: бизнес-логика - это правила предметной области.
2. Приведите пример из frontend: валидация формы, доступность действия, расчет предварительной цены, обработка статуса.
3. Покажите границу: критичные проверки подтверждает backend, а в frontend правила лучше выносить из JSX и тестировать отдельно.

Пример ответа:

Бизнес-логика - это правила продукта: какие действия разрешены, как считаются значения, какие статусы возможны. Во frontend она проявляется в сценариях пользователя, доступности кнопок, локальной валидации и отображении ошибок. Но если правило влияет на деньги, права или сохранение данных, клиентская проверка не должна быть единственной. Я бы вынес повторяемые правила в отдельные функции или доменный слой и покрыл их тестами.

Для кандидата важнее показать не знание термина, а зрелое разделение ответственности. Если все условия живут в компонентах, код становится хрупким: одно правило меняют в одном месте, забывают в другом, и пользователь получает разные ответы на разных экранах.

Если бизнес-логика названа, вынесена и протестирована, ее легче менять вместе с требованиями. А если backend остается финальной проверкой для критичных действий, приложение не ломает данные и не строит безопасность на доверии к браузеру.