Какие правила выстраивания взаимодействия между компонентами модульной системы существуют
Что проверяют
Умеете ли вы как аналитик описать интеграцию так, чтобы разработчики разных команд не додумывали её каждый по-своему. Следом обычно просят показать на примере, как вы задокументируете обмен между двумя модулями и что произойдёт при ошибке.
Как отвечать
Говорите на уровне системы, а не классов:
- один владелец данных: у каждой сущности есть модуль-мастер, и только он её меняет. Остальные читают через его API или получают события. Общая база, в которую пишут все, это нарушение границ;
- явный контракт: взаимодействие фиксируется спецификацией, OpenAPI для синхронных вызовов, AsyncAPI или описание сообщений для брокера. В контракте формат, обязательность полей, коды ошибок;
- зависимости без циклов: если модуль A вызывает B, а B вызывает A, их нельзя развивать и выкатывать независимо. Цикл разрывают событием или выносом общего в третий модуль;
- синхронно или асинхронно: REST или gRPC, когда ответ нужен сразу; очередь (Kafka, RabbitMQ), когда достаточно итоговой согласованности и важно не уронить соседа своей нагрузкой;
- обработка ошибок: тайм-ауты, повторы, идемпотентность повторного запроса, поведение при недоступности соседа. Для процесса через несколько модулей описывается сага с компенсирующими действиями;
- версионирование: изменения контракта обратно совместимы, новые поля необязательны, ломающие изменения идут новой версией с периодом поддержки старой;
- низкая связанность, высокая связность: внутри модуля всё про одну предметную область, между модулями минимум знаний друг о друге.
Покажите артефакты: C4-диаграмма контейнеров для общей картины, диаграммы последовательности для ключевых сценариев, матрица интеграций с источником, частотой обмена и SLA.
Где спотыкаются
Уходят в SOLID и внедрение зависимостей на уровне классов. Для аналитика это не ошибка, но интервьюер ждёт границ модулей и контрактов.
Описывают только успешный сценарий. Интеграцию без раздела про ошибки, тайм-ауты и повторную доставку разработчики додумают сами, и каждый по-своему.
Не определяют мастера данных. В итоге одна сущность меняется в двух местах, и расхождения ищут вручную.