С какой архитектурой вы работали
Что проверяют
Можете ли вы описать систему, в которой работали, как набор компонентов и связей между ними. Аналитика спрашивают не про модные слова, а про то, понимает ли он, куда уходят данные и где заканчивается зона ответственности его требований.
Как отвечать
Начните с контекста: что за система, какие внешние участники, кто кому что передаёт. Дальше опишите внутреннее устройство на том уровне, который вы действительно видели:
- стиль: монолит, ландшафт из нескольких приложений, интеграционная шина. Говорите как есть, монолит это не стыдно;
- интеграции: синхронный REST или SOAP, очередь сообщений, файловый обмен по расписанию, выгрузка в хранилище. Для аналитика это главное, потому что от выбора зависят требования;
- данные: где мастер-система, какие справочники общие, что считается источником истины.
Покажите, как архитектура влияла на вашу работу. Асинхронная интеграция означает, что в требованиях описаны повторная доставка, дубли и идемпотентность по ключу. Файловый обмен требует формата, кодировки, признака завершённости файла и поведения при частичной загрузке. Синхронный вызов требует ответа на вопрос, что делать при таймауте смежной системы.
Если вы рисовали схемы, скажите в какой нотации и на каком уровне: контекст, контейнеры, последовательность вызовов.
Где спотыкаются
Отвечают одним словом «микросервисы». Дальше идёт вопрос, сколько было сервисов и как они общались, и выясняется, что это был монолит с парой модулей.
Подменяют архитектуру системы устройством команды или процессом разработки. Состав команды и длина спринта это не ответ на заданный вопрос.
Не могут назвать протокол и формат обмена. Аналитик, который не знает, идёт интеграция через очередь или синхронным запросом, не напишет проверяемые требования к обработке ошибок.