Знаком ли с архитектурными концепциями

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

Вопрос открытый, и проверяют не список модных слов, а умение связать подход с задачей и показать, как он выглядит в Go-коде. Следом обычно просят нарисовать структуру вашего последнего сервиса или объяснить, где у вас объявлены интерфейсы.

Как отвечать

Назовите концепции и покажите, как они ложатся на Go:

• слоистая и чистая архитектура: хендлер (HTTP или gRPC) вызывает сервис с бизнес-логикой, сервис работает с хранилищем через интерфейс. Зависимости направлены внутрь, домен не импортирует net/http и драйвер базы;
• порты и адаптеры: та же идея с другой стороны. Интерфейс объявляется у потребителя, маленький, на пару методов, а реализация для Postgres или Kafka это адаптер. В Go это естественно благодаря неявной реализации интерфейсов: «accept interfaces, return structs»;
• внедрение зависимостей: через конструкторы вида NewService(repo Repository, log *slog.Logger) и сборку в main. wire или fx нужны только для большого графа;
• структура проекта: cmd/ для точек входа, internal/ для кода, который компилятор не даст импортировать извне. Репозиторий golang-standards/project-layout не официальный стандарт, на этом часто ловят;
• микросервисы и модульный монолит: границы по доменам, общение по gRPC или через брокер, для надёжной публикации событий паттерн transactional outbox. Назовите и цену: распределённые транзакции, сетевые сбои, трассировка;
• событийная архитектура: Kafka или NATS, идемпотентные консьюмеры, потому что доставка обычно «at least once».

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

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

Переносят в Go привычки из Java: огромные интерфейсы рядом с реализацией, пакеты models, utils, services и абстракции «на будущее».

Называют MVC основным выбором для бэкенда на Go. В сервисах без серверного рендеринга HTML этот шаблон почти не встречается.

Хвалят микросервисы без оговорок. Сильнее ответ, где названо условие: несколько команд, разные требования к масштабированию, независимые релизы.