Наилучшая структура Django-проекта?

Проблема
Не могу понять, какая же все-таки наилучшая структура в Django-проектах. Гуглил, но везде все пишут по-разному с припиской "не факт, что это 'правильно', но я делаю так...". А хотелось бы раз и навсегда для себя уяснить, какая же все-таки правильная, гибкая и наиболее логичная структура в Django-проектах?

Что я пробовал?
Django изучаю уже 3 месяца по книге Дронова 2021 года выпуска, и там структура примерно такая:
root_folder/
--.git/
--my_project/
----my_project/
----app_1/
----app_n/
----static/
----template/
----media/
----db.sqlite3
----manage.py
--venv
--.gitignore
--README.md
--requirements.txt


С какими проблемами пришлось толкнуться?
Но, используя такую структуру, я столкнулся с рядом проблем:
  • Когда приложений становится много, становится очень трудно ориентироваться в папке проекта. Есть ли смысл выносить их в папку apps?
  • Где хранить общий код? Например, общие модели, общие шаблоны, общие static-файлы, обычный общий код на Python (какой-то функционал, свои библиотеки, если такие имеются)?
  • Как все-таки правильно работать с settings.py? Я видел примеры, где файл заменяли на пакет settings/, в котором хранились модули dev.py, prod.py, base.py. Но это все были субъективные мнения, надеюсь, никого не обижу, ноу-нейм разработчиков. Есть ли так называемая best practice?
  • Также в силу моей неопытности мне не совсем понятно, куда относить функционал, который не относится ни к одному приложению в проекте, но который достаточно мал, чтобы выносить его в отдельное самостоятельное приложение? Например, страницы "Главная" и "О нас". В одном из моих проектов это небольшие страницы с минимальной логикой. И мне пришлось объединить их в одно приложение main, хотя строго говоря, "Главная" и "О нас" никак не связаны друг с другом, но девать их куда-то нужно было.


К чему я пришел?
Вот, к какой структуре Django-проектов пришел я. Оцените, пожалуйста, или посоветуйте действительно хорошую и универсальную структуру Django-проектов. Для упрощения демонстрации я не стал указывать общепринятые вещи по типу urls.py, asgi.py и т.д.:
root_folder/
--.git/
--my_project/
----core/
------settings/
--------base.py
--------dev.py
--------prod.py
----apps/
------app_1/
------app_n/
----common/
------template/
------static/
------models/
------any_other_module_or_package/
----manage.py
--venv
--.gitignore
--README.md
--requirements.txt
  • Вопрос задан
  • 4040 просмотров
Решения вопроса 1
@rodion4dev
Отвечая на вопрос, увы, таковой нету. Вы должны сами для себя решить и не спустя три месяца.

Но если желаете более предметно, то вот Вам мои ощущения по поводу Вашей структуры, к которой вы пришли...

Первое, что бросается в глаза - настройки. Да, Вы следуете идеологии Django, которая неявно шепчет всем нам как их компоновать: но это небезопасно. Почему в настройках у вас модули, два из которых отражает какое-то окружение (разработка, боевое и что-то общее между тем и тем)? Исходя из Вашей структуры сразу витает в воздухе вопрос: "А почему настройки боевого окружения вдруг должны быть в репозитории? А как быть с секретным ключом? А безопасно ли это?". Следующий логичный вопрос удобства: почему я, как разработчик, вдруг должен заставлять своих DevOps'ов компоновать и поддерживать за меня настройки в виде файлов (модулей)? Это ведь исполняемый файл и там бесчисленное количество возможностей; более того, это не безопасно. Сейчас бОльшая часть проектов поднимается средствами docker-compose, куберов и прочих прелестей: дико неудобно собирать и поддерживать настройки в виде файлов для каждого запускаемого контейнера (у нас ведь есть переменные окружения). Надеюсь, здесь понятен основной посыл: безопасность и удобство использования.

(здесь я не сразу понял, что это именно проект, а не приложение; подробности в комментариях)
Едем дальше - core. Почему именно такое название? Понятное дело, ядро, Django в своих исходниках делает и всё такое... Но зайдя в такой проект, сразу ли будет понятно за что отвечает это приложение? Нет. В общем-то даже в документации к Django в quick start название приложения опирается на её главную бизнес-потребность.

Переходим к следующему: папка apps с приложениями. Для начала вроде всё удобно и логично: есть ядро проекта, а есть дополнения к нему а значит их нужно как-то отделить от этого ядра. А что делать если ядро будет всегда одно в проекте? А что делать если дополнительных приложений будет всего одно? А зачем тогда ему целая папка (приложению) если само приложение - и есть папка (или модуль в нашем случае)? Так оставлять или менять уровень вложенности? На самом деле что core, что appN - являются такими же Django приложениями (одинаковыми), а значит и уровень абстракции у них - один; один уровень абстракции говорит нам о том, что и appN нужно класть где-то рядом с core (здесь должно быть другое название как и писал). Часто я вижу в проектах, что core так и остаётся одой единственной core папкой без дальнейшей расширяемости. Вывод - преждевременная оптимизация - вещь нелогичная по сути своей.

Папка template. Здесь я всегда доверяюсь Django и кладу шаблоны в папку приложения (делая ещё две папки - templates, а в ней - папку с названием приложения). Здесь, думаю, подойдёт правило класть то, что используется, ближе к тому месту, где это используется (но с поправкой на рекоммендации оф. документации Django).

Папка static. В среде отладки её быть в принципе быть не должно; обычно вся статика всегда в первую очередь связана с приложением, куда мы её и стараемся класть (как с папкой templates), что является и советом из Django документации.

Папка models. Вынося её куда-то в отличное от папки приложения место, мы сразу же забиваем на автономность самого приложения; приложение сразу же становится зависимым от внешнего кода (чего нужно избегать). Обычно каждое приложение имеет свои модели и не зависит от моделей другого приложения.

venv. Актуально только на компьютере каждого разработчика; по-моему это неудачное решение класть платформо-зависимые файлы под контроль версий.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
MyNameIsDice
@MyNameIsDice
Работаю с Django(учитывая время изучения) почти год, большую часть времени писал API на DRF(Django REST Framework). Сам тоже интересовался вопросом best practices но везде находил различные подходы. Со временем решил написать свой "best practice" репозиторий ориентированный для DRF что бы быстро начать проект. Время от времени изучая что-то новое обновляю его, можешь ознакомится для формирования своих предпочтений.
(upd: на момент написания ответа он сейчас не в новейшем состоянии)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы