Стоимость абстракции: когда слой вредит

Repository поверх Django ORM может превратить простой запрос в цепочку из интерфейса, адаптера, DTO и нескольких моков. В результате команда получает не изоляцию от базы, а скрытые N+1, неясные границы транзакций и медленное ревью. Разбираем, когда дополнительный слой оправдан, как измерить его цену и где его лучше не ставить. Примеры относятся к Django 5.2 и PostgreSQL 16.

Почему очевидная абстракция начинает мешать

Типичный сценарий выглядит разумно: бизнес-код не должен знать о Django ORM, поэтому команда создаёт интерфейс репозитория, реализацию для PostgreSQL и отдельные объекты передачи данных. Такой подход действительно снижает связанность, если приложение должно работать с несколькими хранилищами или пережить замену модели данных.

Проблема начинается, когда слой добавляют заранее, без конкретной границы изменения. Для одного вызова появляются четыре места, которые нужно прочитать:

• сервис, где вызывается операция;
• интерфейс репозитория с общим названием вроде find или save;
• реализация, где спрятаны фильтры, сортировка и загрузка связей;
• модель Django и миграции, определяющие фактические ограничения.

Читатель кода видит намерение, но не видит цену запроса. Метод с названием «получить заказы пользователя» может выполнить один SQL-запрос, десять запросов из-за ленивой загрузки связей или вернуть неполный объект, который позже потребует обращения к базе.

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

Сноска. Ленивая загрузка — способ, при котором связанный объект или набор данных запрашивается только при первом обращении к нему, а не вместе с основной записью. Она экономит запросы не всегда: в цикле по объектам легко получить классический N+1.

Три подхода и их реальная цена

1. Django ORM непосредственно в прикладном коде

Это не отсутствие архитектуры, а ставка на один явный инструмент. Код обращается к QuerySet и моделям там, где формируется сценарий: например, в сервисе оформления заказа или в обработчике отчёта.

Выигрыш — короткий путь от требования до SQL. Разработчик видит фильтры, select_related, prefetch_related, агрегации и границы транзакции в одном месте. Цена — бизнес-логика знает о Django, поэтому перенос в другой фреймворк или хранилище потребует переработки.

Для монолита на Django 5.2 это часто самый дешёвый вариант, если команда не планирует смену ORM, а модели и бизнес-процессы меняются вместе.

2. Тонкий репозиторий вокруг конкретного сценария

Репозиторий здесь не пытается быть универсальным хранилищем. Он содержит несколько методов под реальные операции: получить заказы для страницы клиента, выбрать доступные остатки, сохранить результат расчёта.

Выигрыш — SQL и оптимизация сосредоточены в одном месте, а прикладной код меньше зависит от структуры таблиц. Цена — интерфейс быстро растёт вместе с требованиями. Это нормальная плата: она показывает, что у системы появились разные сценарии чтения, а не маскирует их универсальным методом.

Такой слой оправдан, когда один и тот же запрос используется в нескольких местах, когда его нужно отдельно профилировать или когда схема хранения заметно отличается от языка предметной области.

3. Универсальный repository и DTO для каждой модели

Универсальный репозиторий обычно строится вокруг операций CRUD: создать, найти, обновить, удалить. DTO отделяет модели Django от остального кода и выглядит как строгая граница.

Выигрыш — единообразная структура и формальная изоляция. Цена — потеря выразительности ORM. Сложный запрос всё равно должен передать наружу сортировку, выбор полей, связанные объекты, агрегации и блокировки. В этот момент универсальный интерфейс либо разрастается десятками параметров, либо начинает скрывать решения, которые критичны для производительности.

Ещё одна цена — двойная модель данных. Поле добавляется в модель Django, DTO, преобразование, тестовые фикстуры и иногда в несколько интерфейсов. Небольшое изменение становится дорогим не из-за базы, а из-за обвязки.

Где слой ломает производительность

Скрытая загрузка связей

Представьте страницу с заказами и именами клиентов. Сервис получает список заказов через репозиторий, а шаблон или сериализатор обращается к каждому клиенту отдельно. На тестовых данных из пяти заказов это незаметно. На странице со ста заказами запросов становится значительно больше, хотя вызов репозитория остался прежним.

Слой должен явно фиксировать форму результата: какие связи загружаются заранее, какие поля выбираются, допускается ли обращение к базе после возврата объекта. Если это невозможно выразить в интерфейсе, интерфейс уже скрывает важную деталь.

Потерянная транзакция

Создание заказа, резервирование остатка и запись платежного намерения должны выполняться в согласованной транзакции. Когда каждая операция спрятана в своём репозитории, граница транзакции может оказаться между вызовами. Один метод завершился успешно, второй упал, а сервис не контролирует, что именно откатилось.

Транзакция должна принадлежать сценарию, который отвечает за целостность операции, а не случайному нижнему слою. Репозиторий может выполнять запросы, но не должен самовольно решать, где начинается и заканчивается бизнес-процесс.

Неясный SQL и слабое наблюдение

При инциденте важно связать медленный endpoint с конкретным запросом. Универсальный метод вроде get_by_id может вызываться в десятках сценариев и возвращать разные объёмы данных в зависимости от последующих обращений к связям. Логи показывают SQL, но не объясняют, почему он был вызван.

Практичный компромисс — именовать методы по сценарию и логировать измеримые признаки: имя операции, число SQL-запросов, суммарное время запросов, объём возвращённых строк. Названия методов не заменяют трассировку, но сокращают путь от симптома к месту в коде.

Как решить, нужен ли слой

Оценивать абстракцию стоит не по количеству интерфейсов, а по стоимости изменения. Перед добавлением репозитория ответьте на четыре вопроса:

1. Что именно меняется? Если ожидается замена PostgreSQL на другой движок, это должна быть проверяемая цель, а не гипотеза «когда-нибудь пригодится».
2. Где проходит граница? Если слой не может объяснить, какие данные он возвращает и кто управляет транзакцией, он скрывает больше, чем изолирует.
3. Как измерить эффект? Нужны число SQL-запросов, время на запросы, время endpoint и объём данных до и после изменения.
4. Как выглядит тест без мока ORM? Если тест проверяет только вызов метода репозитория, но не проверяет SQL-семантику и ограничения базы, он может пропустить N+1 и ошибку транзакции.

Для замера в Django 5.2 зафиксируйте одинаковые данные, число объектов на странице, версию PostgreSQL 16, тип окружения и параллельность. Сравнивайте не только среднее время, но и p95, число запросов и объём ответа. Если нагрузочного стенда нет, честно ограничьте вывод локальным сравнением: оно покажет направление, но не поведение в проде.

Когда что выбирать

Оставляйте ORM в прикладном коде, если запрос локален, хорошо читается и меняется вместе со сценарием. Это особенно разумно для административных экранов, внутренних инструментов и небольшого монолита.

Выносите запрос в тонкий репозиторий, если он повторяется, требует оптимизации или должен быть согласован между несколькими сценариями. Метод должен возвращать понятный результат, а не универсальный набор флагов.

Не вводите универсальный слой только ради «чистой архитектуры». Он оправдан, если есть конкретная граница: несколько реализаций хранилища, отдельная команда с независимым контрактом или необходимость изолировать нестабильную интеграцию. Даже тогда оставляйте сложные запросы явными и документируйте форму данных.

Что проверять на ревью и в проде

• Видно ли по вызову, сколько данных он возвращает и какие связи загружает?
• Не спрятана ли граница транзакции между двумя операциями, которые должны быть атомарными?
• Не превращается ли интерфейс в набор параметров для каждого нового фильтра?
• Есть ли тест на число запросов для критичного сценария?
• Можно ли по метрике или трассировке найти конкретный медленный запрос?

Граничный случай — аналитические выборки. Они часто требуют агрегаций, оконных функций, явного выбора полей и другого времени жизни данных. Прятать их под тот же CRUD-репозиторий, что и операции с одной записью, обычно вредно: читателю кода становится непонятно, что перед ним отчётный запрос с другой стоимостью.

Инвалидация кеша и выбор между ORM и сырым SQL — отдельные темы. Здесь важнее граница абстракции: она должна сделать стоимость операции заметной, а не убрать её из поля зрения.

Что сделать дальше

Возьмите один медленный или часто меняющийся сценарий и зафиксируйте его до рефакторинга: время endpoint, p95, число SQL-запросов, количество возвращённых строк и границу транзакции. Затем сравните прямой ORM-вызов с тонким предметным репозиторием на тех же данных. Если слой не сокращает стоимость изменений и не улучшает наблюдаемость, его лучше не добавлять. Следующий практический шаг — включить сбор SQL и трассировку критичных endpoint, а не создавать ещё один интерфейс.