---
title: Архитектура Python-приложения
questionDates:
  q-transfer-0265: '2026-10-01'
  q-transfer-0266: '2026-10-01'
  q-transfer-0267: '2026-10-01'
  q-transfer-0284: '2026-10-01'
seo:
  description: >-
    Тема «Архитектура Python-приложения» для собеседования Python Developer.
    Какую границу задает паттерн Repository? Как отличить доменную сложность от
    привнесенной?
  title: Архитектура Python-приложения — Python Developer
---

[Все темы Python Developer](/prep/python-developer)

## Какую границу задает паттерн Repository? [#q-transfer-0265]

Repository задает приложению интерфейс загрузки и сохранения доменных агрегатов, скрывая детали ORM и запросов. Транзакционная граница обычно находится выше, например в unit of work или application service, чтобы несколько операций фиксировались вместе. Паттерн полезен при богатой domain-модели или сменяемом хранилище. Тонкая копия всех методов ORM лишь добавляет слой и лишает вызывающего полезных возможностей запросов. Дополнительный слой оправдан, когда задает устойчивую границу ответственности и уменьшает число зависимостей бизнес-правила.

:::note[Ссылки для изучения]

1. [Repository как граница домена и хранения: отличие от DAO и лишних обёрток ORM](https://habr.com/ru/companies/multifactor/articles/1046377/)
   :::

---

## Как отличить доменную сложность от привнесенной? [#q-transfer-0266]

Доменная сложность следует из бизнеса: тарифы, сроки, права, исключения и инварианты останутся при смене фреймворка. Привнесенная сложность появилась из выбранной архитектуры, инфраструктуры или дублирования. Первую моделируют именованными типами и правилами, вторую сокращают, измеряя пользу каждого слоя. Хорошая проверка: может ли эксперт предметной области объяснить правило и исчезнет ли оно при замене технологии. Дополнительный слой оправдан, когда задает устойчивую границу ответственности и уменьшает число зависимостей бизнес-правила.

:::note[Ссылки для изучения]

1. [Неотъемлемая и привнесённая сложность: различие задачи пользователя и реализации](https://habr.com/ru/companies/ruvds/articles/824058/)
   :::

---

## Когда использовать Router, а когда urlpatterns в DRF? [#q-transfer-0267]

`urlpatterns` выбирают для явных function/class views и нестандартных маршрутов. Router автоматически строит CRUD URL для ViewSet; `SimpleRouter` дает основные маршруты, `DefaultRouter` дополнительно корневое API и форматные варианты. `@action(detail=..., methods=[...])` добавляет нестандартное действие. `basename` нужен, если его нельзя вывести из queryset. Маршрут должен выражать ресурс, а не прятать произвольный RPC за CRUD-именем. Дополнительный слой оправдан, когда задает устойчивую границу ответственности и уменьшает число зависимостей бизнес-правила.

:::note[Ссылки для изучения]

1. [Роутеры DRF: автоматические URL для ViewSet, basename и дополнительные @action](https://proproprogs.ru/django/drf-simplerouter-i-defaultrouter)
   :::

---

## Когда не стоит использовать context processor? [#q-transfer-0284]

Django context processor добавляет общие данные в контекст шаблонов и имеет доступ к request. Он выполняется при рендеринге подходящего шаблона, поэтому тяжелый запрос, внешний I/O или бизнес-операция незаметно удорожают многие страницы. Данные конкретной view передают явно, бизнес-логику держат в сервисе, а сквозную обработку запроса выполняет middleware. Processor должен возвращать небольшой словарь дешевых значений. Дополнительный слой оправдан, когда задает устойчивую границу ответственности и уменьшает число зависимостей бизнес-правила.

:::note[Ссылки для изучения]

1. [Общие данные context processor и явный контекст представления — документация Django](https://djangodoc.ru/5.0/ref/templates/api/)
   :::