На какие паттерны и шаблоны опираются при проектировании архитектуры сервисов?

Что проверяют

Как вы обращаетесь с размытым вопросом и есть ли у вас словарь для разговора об архитектуре за пределами отдельных компонентов. Для фронтендера тут два прочтения: слой работы с бэкендом внутри клиента и устройство приложения целиком.

Как отвечать

Сначала уточните, о каких сервисах речь, и дальше говорите про свою зону ответственности. Что стоит назвать:

• однонаправленный поток данных: состояние меняется через явные действия, представление только читает. Это база предсказуемой отладки;
• разделение серверного и клиентского состояния: кэш ответов с ключами, инвалидацией и фоновым обновлением отдельно от состояния интерфейса. Смешивать их в одном хранилище больно;
• слой доступа к данным: один клиент с базовым адресом, обработкой ошибок, авторизацией и повторами, а не fetch вразнобой по всему коду;
• нарезка по функциональности, а не по типам файлов: модуль держит рядом экран, запросы и модель, что ограничивает радиус правки;
• отдельный слой под нужды клиента, собирающий данные из нескольких сервисов в форму, готовую для экрана.

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

Закончить лучше компромиссом: какое решение приняли и чем за него заплатили.

Где спотыкаются

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

Пересказывают практики прошлого десятилетия как текущие. Деление на умные и глупые компоненты появилось до хуков, и сегодня логика выносится в хук, а не в компонент-обёртку ради обёртки.

Тащат тяжёлое глобальное хранилище на любую задачу. Большая часть состояния это либо кэш серверных данных, либо локальное состояние экрана, и глобальным нужно делать только то, что действительно общее для приложения.