На каком архитектурном паттерне основан Django и какие его основные компоненты

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

Понимаете ли вы, что слово «view» в Django значит не то же, что в учебниках по MVC, и можете ли провести запрос по компонентам от адреса до ответа. Вопрос вводный, ответ на него задаёт глубину дальнейшего разговора.

Как отвечать

Django описывает себя как MTV: модель, шаблон, представление. Это тот же MVC, но роль контроллера берёт на себя сам фреймворк. Соответствие такое: модель это модель, шаблон отвечает за отображение, а вьюха ближе к контроллеру, она принимает HttpRequest, обращается к моделям и возвращает HttpResponse.

Путь запроса удобно проговорить целиком: сервер по WSGI или ASGI передаёт запрос, тот проходит цепочку middleware, URLconf по urls.py подбирает вьюху, вьюха берёт данные через ORM (Model.objects), отдаёт контекст в шаблон и возвращает ответ, который снова идёт через middleware.

Компоненты, которые стоит назвать помимо трёх букв: ORM и миграции, маршрутизация, middleware, формы, встроенная админка, аутентификация и права, сигналы, а также приложения из INSTALLED_APPS как единица переиспользования. Для API вместо шаблонов обычно берут DRF с сериализаторами, и слой представления выглядит иначе.

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

Говорят, что это то же MVC, просто названия другие, а на вопрос про контроллер теряются. Достаточно сказать, что маршрутизацию и вызов берёт на себя фреймворк, отдельного класса контроллера в проекте нет.

Кладут бизнес-логику во вьюхи. Ожидается тонкая вьюха, а логика в моделях, менеджерах или отдельном слое сервисов, иначе следующий вопрос будет про тестируемость.

Останавливаются на трёх буквах и не упоминают ORM. Именно про неё спросят дальше, и первым делом про проблему N+1 и про то, что лечится она через select_related и prefetch_related.