Что такое чистая архитектура

Чистая архитектура отвечает на вопрос: что в приложении должно быть стабильным, а что можно заменить с минимальным ущербом. Внутри находится ядро: правила предметной области и сценарии приложения. Снаружи находятся детали: UI-фреймворк, API-клиент, браузерные API, роутер, analytics, storage.

Главная мысль для ответа простая. Внутренний код не должен знать о внешних деталях. Если use case импортирует axios, вызывает localStorage или возвращает React-элемент, он уже привязан к инфраструктуре. Тогда смена API-клиента, SSR-ограничения или новый экран могут потянуть переписывание бизнес-логики.

На интервью не обязательно рисовать классические круги Роберта Мартина. Достаточно объяснить правило зависимостей, слои и практическую пользу: меньше связанности, проще тесты, безопаснее изменения.

Хорошая формулировка может быть такой:

Я понимаю чистую архитектуру как разделение приложения на стабильное ядро и внешние детали. React-компоненты, роутер, API-клиент и storage находятся ближе к внешнему слою. Сценарии приложения и доменные правила не должны зависеть от них напрямую. Поэтому компонент может вызвать use case, а use case работает через интерфейс repository или gateway.

Такая фраза показывает не только знание термина, но и связь с ежедневной frontend-разработкой. Вы не обещаете магически заменить React на Vue за день. Вы говорите точнее. Если логика отделена от UI и инфраструктуры, область изменений становится меньше.

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

Плохой вариант: use case напрямую знает про fetch, форму ответа сервера и не задает границу для ошибок или отмены. Такой код сложнее тестировать. Еще хуже, если его потом вызывают из useEffect без AbortController. При быстрой смене userId старый ответ может перезаписать новый профиль в UI, а ошибка сети превратится в непонятное пустое состояние.

// Плохо: сценарий зависит от HTTP, DTO и не проверяет ответ
export async function loadProfile(userId: string) {
  const response = await fetch(`/api/users/${userId}`);
  const dto = await response.json();

  return {
    name: dto.full_name,
    isActive: dto.is_active,
  };
}

Более безопасный вариант: use case зависит от контракта. Конкретный HTTP-клиент, проверка response.ok, mapper DTO, нормализация ошибок и отмена запроса живут на внешней границе.

type Profile = {
  name: string;
  isActive: boolean;
};

type ProfileRepository = {
  getById(userId: string): Promise<Profile>;
};

export async function loadProfile(
  userId: string,
  repository: ProfileRepository,
) {
  const profile = await repository.getById(userId);

  if (!profile.isActive) {
    return { ...profile, warning: "Профиль неактивен" };
  }

  return profile;
}

Здесь сценарий можно протестировать без браузера, сети и React. Если завтра вместо fetch будет другой клиент или изменится DTO, вы меняете адаптер, а не правило сценария. В React-слое остается понятная задача: создать AbortController при запросе, передать signal в HTTP-адаптер, отменить запрос в cleanup, показать loading, error или empty state и не применять результат отмененного запроса.

Чистая архитектура не требует превращать каждую кнопку в отдельный слой. Если код просто раскрывает dropdown, переключает tab или форматирует локальную подпись, он может остаться рядом с компонентом. Проблема появляется, когда в компоненте смешиваются правила доступа, маппинг API, обработка ошибок, аналитика и сложный сценарий сохранения.

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

Тестируемость здесь не самоцель, а следствие слабой связанности. Если use case получает зависимости через аргументы или через контейнер на внешнем уровне, его можно проверить обычным unit-тестом. Вам не нужно поднимать DOM, мокать router и настраивать сетевой слой ради проверки бизнес-правила.

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

MVC, MVVM, hooks, контейнерные компоненты и feature-based структура не конфликтуют с чистой архитектурой сами по себе. Они чаще описывают организацию внешнего слоя или слоя представления. Чистая архитектура находится уровнем выше и задает вопрос: кто от кого зависит.

Поэтому сильный ответ не спорит, какой паттерн правильный. Он показывает, что React-хук может быть адаптером к use case, view model может готовить данные для экрана, а доменное правило все равно не должно импортировать JSX или браузерный API.

Если вас спрашивают про чистую архитектуру, отвечайте по цепочке: определение, правило зависимостей, frontend-пример, польза и ограничение. Так ответ звучит спокойно и прикладно.

Короткая структура ответа:

1. Приложение делится на слои.
2. Зависимости направлены к ядру, а не к UI и инфраструктуре.
3. Во frontend это отделяет React-компоненты и API-адаптеры от сценариев и правил.
4. Польза: проще тестировать, менять API, переиспользовать логику и контролировать регрессии.
5. Цена: больше кода и договоренностей, поэтому подход нужен там, где сложность уже есть или скоро появится.