> **Ключевые выводы:**  
> - Приложения Django — это не просто отдельные папки.  
> - Это скорее **единица разделения бизнес-доменов**, чем единица развёртывания.  
> - В [[ДРФ]] они работают как модули для разных функций API, и их преимущества очевидны.  
> - В обычных веб-приложениях Django поначалу их необходимость может быть не столь очевидна.  
> - Однако по мере роста проекта разница становится значительной в управлении моделями, панелью администратора, тестами и миграциями.  
> - Хорошо спроектированное приложение становится **многоразовым активом**, который можно перенести в другие проекты.  


Даже если проект [[Джанго]] развёртывается на одном сервере, его можно разделить на несколько приложений с помощью команды `startapp`.
Эта структура особенно естественна для Headless API-серверов на базе DRF, но разделение на приложения по-прежнему имеет смысл и для веб-приложений Django на основе шаблонов.


![Концептуальная схема структуры проекта Django](/media/whitedec/blog_img/fc8aa3e622234c4689779c58a2b8b32e.webp)


## Почему разделение приложений хорошо подходит для DRF {#sec-f9d183702e4a}

* Чёткие границы API

  * `accounts`
  * `posts`
  * `billing`
  * `notifications`

* Каждое приложение работает как независимый набор API

  * models
  * serializers
  * views / viewsets
  * permissions
  * urls
  * tests

* Возможность расширять различные функции стандартным способом в рамках одного DRF-сервера.

* Разные приложения в одном проекте могут создавать неожиданные синергии.

  * Публикация записи → создание уведомления
  * Статус оплаты → изменение прав пользователя
  * Настройки пользователя → изменение способа отображения контента

## Вопросы, возникающие в обычных веб-приложениях Django {#sec-5b615e36b016}

В веб-приложениях Django на основе шаблонов, даже если разделить на приложения, в конечном итоге:

* Они выполняются на одном сервере
* Используют одну и ту же базу данных
* Имеют общие настройки (settings)
* Объединены в одну единицу развёртывания
* Потоки шаблонов также легко смешиваются.

Поэтому в небольших веб-приложениях может возникнуть вопрос: «Действительно ли нужно разделять на приложения?»

## Причины для разделения приложений {#sec-ba9a819246}

* Предотвращает разрастание моделей
* Панель администратора организована по доменам
* История миграций разделена по приложениям
* Легче тестировать только определённое приложение
* Помогает предотвратить «спагетти-код», заставляя учитывать структуру импортов
* Границы уже созданы, что облегчает последующее разделение функций или их преобразование в API.

## Приложения могут стать многоразовыми компонентами {#sec-0f9d2f3a0f0a}

Структура приложений Django позволяет создавать функции как **Plug-and-Play компоненты**.

Даже если приложение создано внутри проекта, при правильной структуре его легко перенести в другой проект.

Например:

* Функция уведомлений → `notifications`
* Функция тегов → `tags`
* Функция оплаты → `billing`

Создав такие приложения независимо, их можно повторно использовать в следующем проекте следующим образом:

* Скопировать папку приложения
* Добавить в `INSTALLED_APPS`
* Подключить необходимые URL
* Выполнить миграции
* Настроить шаблоны или параметры под проект.

Известные библиотеки в экосистеме Django также предоставляются таким образом.

* `django-allauth`: предоставляет функции регистрации, входа в систему и входа через социальные сети в виде приложения

* `django-taggit`: предоставляет функцию тегов как многоразовое приложение

* `django-tailwind`: интегрирует среду разработки Tailwind в проект Django в виде приложения.

То есть приложение Django — это не просто «папка внутри моего проекта», а при хорошем проектировании оно может стать **функциональным активом**, который можно повторно использовать в других проектах.


## Критерии хорошего разделения {#sec-638181ef3b61}

Признаки, указывающие на необходимость разделения приложений:

* Наличие независимой модели данных
* Необходимость отдельной группы Admin
* Наличие собственной бизнес-логики
* Желание запускать тесты отдельно
* Потенциальная возможность отделения в API или отдельный сервис в будущем
* Название функции описывается как домен сервиса
* Возможность повторного использования в других проектах.

Примеры:

* `accounts`
* `billing`
* `notifications`
* `support`
* `analytics`


## Заключение {#sec-85c066cfb297}

Разделение приложений в проекте [[Джанго]] — это

> Структура, позволяющая управлять сложностью, сворачивая её в понятные человеку единицы по мере роста проекта.

И, более того:

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

В [[ДРФ]] это преимущество проявляется сразу, поскольку оно хорошо согласуется с границами API,
тогда как в обычных веб-приложениях Django его ценность становится очевидной по мере роста проекта или начала создания нескольких проектов.