РекомендуетсяDjango 5.2

Django: приложения, имена и безопасная инициализация

Оформляйте предметную область как Django application с устойчивым именем, URL namespace и миграциями. При импорте модулей и в AppConfig.ready не выполняйте бизнес-записи и запросы к БД.

Опубликовано 13 ноября 2026 г.Проверено 13 ноября 2026 г.Изменено 13 ноября 2026 г.

Скачать Markdown Предложить изменение на GitHub Предложить правку

Плохо

# orders/apps.py
from django.apps import AppConfig
from .models import Order
 
class OrdersConfig(AppConfig):
    name = "orders"
    def ready(self):
        Order.objects.filter(status="new").update(status="sent")

Хорошо

# orders/apps.py
from django.apps import AppConfig
 
class OrdersConfig(AppConfig):
    default_auto_field = "django.db.models.BigAutoField"
    name = "orders"
 
# settings.py: INSTALLED_APPS содержит "orders.apps.OrdersConfig".
# orders/urls.py:
# app_name = "orders"
# urlpatterns = [path("<int:pk>/", views.detail, name="detail")]
# Миграции приложения хранятся в orders/migrations/.

Почему это важно

App registry и management commands инициализируют приложение в разных условиях, в том числе до миграций. Запрос или запись при startup может обращаться к неподготовленной БД и повторяться при каждом процессе.

Когда применять

Django 5.2, Python-версия из поддерживаемого профиля проекта. Имена Python-пакетов и функций — snake_case, классов — CapWords по принятому Python-стилю. Это соглашения проекта/Python, а имена models.py, apps.py и AppConfig.name связаны с механизмами Django.

Разделяйте project configuration и приложения предметных областей; небольшой application не обязан иметь service/repository слой. models описывают данные, views — HTTP-адаптер, urls — маршруты, templates — представление. Если models разделены по файлам, их обнаружение и импорт остаются явными.

AppConfig.name — полный Python-путь, label должен быть уникальным и устойчивым: его изменение после миграций затрагивает ссылки Django. Не переименовывайте label как косметическую правку. Для URL используйте именованные маршруты и app_name там, где возможны совпадения.

В ready допустима регистрация signals при необходимости, но она должна быть безопасна к повторной инициализации; не используйте signal как невидимый универсальный слой бизнес-процесса. DB-операция выполняется в явном request/service/management command, а связанные записи подчиняются atomic-контракту.

Кто что делает

Человек

Определяет границы приложений и устойчивые имена, согласует изменения labels.

AI-агент

Проверяет чистый startup, AppConfig и миграции. Не выполняет данные/внешние эффекты из ready или module import.

Как проверить у себя

Вход и действие	Ожидаемый результат	Свидетельство
Новая БД, check/migrate и запуск	Startup не требует уже созданных таблиц приложения	Лог чистой установки
Два приложения имеют detail route	reverse с namespace выбирает нужный URL	Тест маршрутизации
Повторная инициализация приложения/несколько worker	Нет повторных записей и дубликатов signals	Счетчик вызовов
Предложено переименование app label	Проверены зависимости миграций и обратная совместимость	План миграции, не массовая замена строки

Проверка импорта Python без Django registry не доказывает корректную загрузку application.

Первоисточники

История изменений на GitHub

Дата проверки отражает содержательную сверку. Синхронизация сайта не обновляет её автоматически.