Какую архитектуру вы бы выбрали для годового проекта
Что проверяют
Умеете ли вы выбирать архитектуру от требований, а не от моды, и понимаете ли, во что каждое решение обойдётся через год. Следом обычно спрашивают, в какой момент вы бы разделили систему на микросервисы.
Как отвечать
Сначала задайте вопросы, это часть ответа: сколько людей в команде, какая нагрузка, насколько сложна предметная область, сколько внешних интеграций, кто будет поддерживать систему после сдачи. Без этого любой выбор выглядит угадыванием.
Для типичного случая, одна команда и год разработки, разумный выбор на .NET такой:
- модульный монолит: одно приложение на ASP.NET Core, но модули по бизнес-областям с явными границами и без прямого доступа к таблицам друг друга;
- слои внутри модуля: Clean Architecture (Domain, Application, Infrastructure, API) или vertical slices, если логика в основном CRUD и слои превращаются в пустые прослойки;
- данные: EF Core с миграциями, PostgreSQL или SQL Server, для тяжёлых запросов точечно Dapper;
- контроль границ: архитектурные тесты на NetArchTest или ArchUnitNET, чтобы модули не срастались со временем;
- тесты и поставка: xUnit, интеграционные тесты через
WebApplicationFactoryи Testcontainers, CI с первого спринта.
Объясните, почему не микросервисы: они решают проблему многих команд и независимых релизов, а одна команда за год получит в основном накладные расходы на сеть, распределённые транзакции и наблюдаемость. Модульный монолит оставляет дорогу к выделению сервиса позже, когда появится реальная причина. Платформу берите в LTS-версии, сейчас это .NET 10.
Где спотыкаются
Сразу предлагают микросервисы с Kubernetes и шиной сообщений для проекта одной команды. Интервьюер слышит выбор ради строчки в резюме.
Тащат полный набор слоёв, репозиториев и маппингов в простой CRUD. Каждая фича начинает требовать правки в пяти проектах, и к середине года скорость падает.
Не спрашивают про требования и не называют условия, при которых решение поменяется. Сильный ответ звучит как «выбираю это, пока верно вот это».