Что такое архитектура

На интервью важно не дать школьное определение, а показать практический смысл. Архитектура отвечает на вопрос: как устроить систему так, чтобы ее можно было менять, расширять, тестировать и понимать без постоянных поломок.

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

Хорошая короткая формулировка:

Архитектура это набор решений о частях системы, их ответственности и связях. Она нужна, чтобы частые изменения были предсказуемыми, а код не превращался в набор случайных зависимостей.

В frontend-ответе лучше быстро перейти от общего определения к коду. Покажите, что вы понимаете типичные границы:

• UI-компоненты отвечают за отображение и пользовательские события.
• API-слой знает, как общаться с backend и обрабатывать технические детали запросов.
• Бизнес-правила не должны случайно размазываться по JSX.
• Общее состояние должно иметь понятного владельца, иначе появляются рассинхронизация и лишние рендеры.
• Общие компоненты не должны зависеть от конкретных страниц и фич.

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

Плохой пример: компонент делает все сразу. Он рендерит UI, ходит в API, содержит бизнес-условия и сам решает, куда перейти после успеха.

function CheckoutButton({ cart }) {
  const [loading, setLoading] = useState(false);

  async function handleClick() {
    setLoading(true);

    const discount = cart.items.length > 3 ? 0.1 : 0;

    const response = await fetch("/api/orders", {
      method: "POST",
      body: JSON.stringify({ cart, discount }),
    });

    if (response.ok) {
      window.location.href = "/success";
    }

    setLoading(false);
  }

  return <button onClick={handleClick}>{loading ? "Loading" : "Pay"}</button>;
}

Такой код может работать, но архитектурно он хрупкий. Правило скидки трудно переиспользовать и тестировать отдельно. Ошибка запроса не обрабатывается, поэтому пользователь не понимает, что заказ не создан. При исключении loading останется true. Повторный клик может отправить два заказа. Если компонент размонтируется во время запроса, легко получить обновление состояния после ухода со страницы. Навигация, API и бизнес-логика смешаны с UI.

Более безопасное направление: вынести расчет в отдельную функцию, запрос в API-слой, а компонент оставить местом, где пользователь запускает действие и видит состояние. В API-слое можно централизованно добавить Content-Type, обработку неуспешного ответа, AbortSignal и правила авторизации.

function calculateDiscount(items: CartItem[]) {
  return items.length > 3 ? 0.1 : 0;
}

async function createOrder(cart: Cart, signal?: AbortSignal) {
  const response = await fetch("/api/orders", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ cart, discount: calculateDiscount(cart.items) }),
    signal,
  });

  if (!response.ok) {
    throw new Error("Order was not created");
  }

  return response.json();
}

Компонент все еще отвечает за UX: блокирует повторную отправку, показывает ошибку, возвращает фокус к понятному месту и очищает запрос при уходе со страницы. На интервью не обязательно писать идеальную схему. Достаточно объяснить, что разделение ответственности уменьшает связность и делает изменения безопаснее.

Сильный ответ не звучит как список модных слов. Лучше показать критерий выбора: архитектура должна защищать от самых вероятных изменений и рисков в продукте.

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

Архитектура не создается один раз навсегда. Обычно команда начинает с простого решения, смотрит на частые изменения, замечает места боли и усиливает границы там, где это окупается.

Опасность в двух крайностях. Первая: вообще не думать о границах, пока проект не станет дорогим для изменений. Вторая: заранее внедрить сложную схему, которую команда не понимает и не может поддерживать.

Можно ответить так:

Архитектура для меня это не только папки. Это решение о том, какие части есть в системе, за что они отвечают, как они зависят друг от друга и как через них проходит состояние и данные. Во frontend я смотрю на разделение UI, API-запросов, бизнес-логики и состояния. Хорошая архитектура позволяет менять частые сценарии локально, тестировать код и не получать регрессии от каждой фичи.

Если хотите усилить ответ, добавьте короткий пример из опыта, но без выдуманных деталей:

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