Архитектура универсального проекта Django / forpes.ru

Главная
Архитектура универсального проекта Django

Архитектура универсального проекта Django +9

11.10.2022 01:52

Lev_Antropov 15 4700 Источник

Введение

В ходе последних лет моей разработки проектов Django я понял, что почти все они имеют одно строение.

Перейти на схему(п.8), кому нужна только схема без объяснений.

1. Poetry - создание общей директории

$ poetry new maindir
$ tree maindir
maindir/
├── maindir
│   └── init.py
├── pyproject.toml
├── README.rst
└── tests
├── init.py
└── test_maindir.py

"Maindir" в данном случае названа так, чтобы показать, что это исходная директория. В реальной жизни у вас будет название проекта.

2. Установка зависимости Django

$ poetry shell
$ poetry add django

3. Создание проекта Django

3.1 Переименовываем внутреннюю директорию maindir to src

$ cd maindir
~/maindir
$ mv maindir src
$ cd src

3.2 Создаем проект Django внутри папки src

~/maindir/src
$ django-admin startproject config .

3.3 Удаляем tests/ и README.rst

получаем:

$tree maindir
maindir/
├── poetry.lock
├── pyproject.toml
└── src
├── config
│   ├── asgi.py
│   ├── init.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── init.py
└── manage.py

4. Инициализация Git

$ git init
$ touch .gitignore
$ touch README.md

5. Промежуточный итог

maindir/
├── .git
│   ├── ...
├── .gitignore
├── poetry.lock
├── pyproject.toml
├── README.md
└── src
├── config
│   ├── asgi.py
│   ├── init.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── init.py
└── manage.py

Проект Django находится в директории src.

Остальные файлы и приложения на одном уровне с src/, то есть внутри главной директории всего проекта maindir): например, .gitignore, Dockerfile, deploy/, setup.cfg, poetry.lock и т.д.

6. Открытие проекта в PyCharm

Если вы не используете PyCharm, можете пропустить этот этап, продолжая работать, например, из командной строки без потери функциональности.

6.1 Открываем в PyCharm директорию maindir
6.2 Выбираем виртуальное окружение.
6.2.1 Для этого заходим File/Settings/Project: maindir/Python Interpreter
6.2.2 Жмем "add interpreter", далее "add local interpreter", выбираем Poetry Environment, далее Existing Environment и находим наше окружение по имени или пути, созданное в 1-2 пунктах.
6.3 Указываем PyCharm где нужно применять Django (File/Settings/Languages & Frameworks)

6.4 Помечаем директорию src/ как ресурсную, для этого правой кнопкой мыши кликаем по src, наводим в появившемся окне "Mark Directory as" и выбираем Sources Root.

7. Создание директорий проекта Django

7.1 APPS/

~/maindir/src
$ mkdir apps
$ touch apps/__init__.py

Или в PyCharm кликаете по src, выбираете New, далее Python Package.
Далее по тексту будем пользоваться именно этим способом.

Абсолютно все приложения django создаются внутри директории apps/.
Чтобы django адекватно подхватывал приложения из apps/, необходимо будет сделать небольшую настройку после создания каждого приложения.

Давайте создадим для примера приложение payment внутри apps/ и настроим:

~/maindir/src
$ mkdir apps/payment
$ ./manage.py startapp payment apps/payment
$ tree

├── apps
│   ├── __init__.py
│   └── payment
│       ├── admin.py
│       ├── apps.py
│       ├── __init__.py
│       ├── migrations
│       │   └── __init__.py
│       ├── models.py
│       ├── tests.py
│       └── views.py
├── config
...

Отредактируем файл apps/payment/apps.py вот так:

И добавим приложение в config/settings.py

...

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'apps.payment.apps.PaymentConfig'
]

...

7.2 API/

Все views.py собираются в этой директории.

Поэтому смело удаляем apps/payment/views.py

Также внутри api/ создаем две директории auth/ и v1/

auth/ - в любом случае, я всегда всегда делаю свою аутентификацию (например, по токену), а также всякие permissions для эндпоинтов API и т.д.

v1/ - версия API, здесь собираются директории (python package, тождественные названию приложений в apps), в которых уже находятся views.py

7.3 UTILS/

Вспомогательный код.

В эту директорию запрещается любой импорт из api/ и apps/, и других директорий проекта.

7.4 LIBRARY/

Код для работы с другими API, системами и т.д.

В эту директорию запрещается любой импорт из api/ и apps/, и других директорий проекта, кроме utils/.

7.5 WORKERS/

Задания для Celery

8 Итого: минимальная архитектура проекта Django

├── api
│   ├── __init__.py
│   └── auth
│   │   ├── auth.py
│   │   └── permissions.py
│   └── v1
│       ├── payment
│       │    ├── __init__.py
│       │    └── views.py
│       ├── __init__.py
│       └── urls.py

├── apps
│   ├── __init__.py
│   └── payment
│       ├── admin.py
│       ├── apps.py
│       ├── __init__.py
│       ├── migrations
│       │   └── __init__.py
│       ├── models.py
│       ├── tests.py
│       └── views.py
├── config
│   ├── asgi.py
│   ├── __init__.py
│   ├── __pycache__
│   │   ├──...
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── library
│   ├── youtube
│   │   ├── __init__.py
│   │   ├── videos.py
│   │   └── ...
│   ├── __init__.py
│   └── ...
├── utils
│   ├── __init__.py
│   ├── numbers.py
│   └── ...
├── workers
│   ├── payment
│   │   ├── __init__.py
│   │   └── tasks.py
│   ├── __init__.py
│   └── ...
├── __init__.py
└── manage.py

P.S.

На самом деле я еще разбиваю config/, а также каждое приложение в директории apps/, но об этом подробнее в другой статье.

Комментарии (15)

Tanner
11.10.2022 01:57
#24808422
+4
Следующий логичный шаг – написать свой cookiecutter.
1. Lev_Antropov Автор
  11.10.2022 06:19
  #24808552
  Можно и шаблон сделать, вы правы. Я так и не сделал))

Nireko
11.10.2022 06:24
#24808558
В Pycharm также django доступна как framework в настройках
1. Lev_Antropov Автор
  11.10.2022 07:17
  #24808596
  Можете подробнее раскрыть уточнение? Вроде бы в п.6 я раскрываю этот момент, или вы имеете в виду, что можно в PyCharm сразу создать проект Django?
  1. Nireko
    11.10.2022 07:38
    #24808606
    Если указывать настройку django в pycharm, то вот хороший пример того, что можно сделать https://www.jetbrains.com/help/pycharm/django-support7.html
1. igor6130
  11.10.2022 12:26
  #24809392
  +1
  Не забудьте уточнить, что это возможно только в платной профессиональной версии. В бесплатной такая возможность отсутствует.

Tuki_Tip
11.10.2022 09:54
#24808834
+6
Все круто, но не стоит забывать о том, за что мы любим Django. Это не только DjangoORM(хотя, конечно это в большей степени), миграции и механизм конфигов из под капота и т.д. Мы любим ее еще и за то, а многие ровно за это же ее нелюбят, что она рекомендует свою, стандартную структуру проекта.

Возмем тот же Flask, что не проект, то униакльная структура и хорошо если она логична. Вхождение нового разработчика в проект на Flask это всегда вызов. В Django же все по другому. Если разработчик читал документацию Django и структура проекта этой документации соответствует, то он уже на старте много чего знает и сможет в кратчайшие сроки ориентироваться по кодовой базе. А для некоторых информация о том, что проект на Django, формирует ожидание к структуре и в целом кодовой базе. И разработчик будет испытывать негатив, когда его ожидания не будут оправдываться.

Если выбрали Django, то хорошей стратегией на перспективу будет, как можно строже, придерживаться документации. Каждое отклонение удорожает поддержку и вход новых разработчиков. Поэтому, небольшая рекомендация для тех кто только входит в индустрию и тех, кто еще не строит планов по развитию и ведению кодовой базы на дистанции, прежде чем вносить изменение в структуру проекта, отличное от рекомендаций Django, посоветуйтесть с тех.лидом или тем, кто эту роль выполняет у вас в команде/компании.
1. MAXH0
  11.10.2022 12:08
  #24809326
  -1
  "Хорошей стратегией на перспективу" >> для вашего нанимателя. А если разработчик работает ИП, то он, скорее, заинтересован, чтобы с правками опять обратились к нему. Так что возможны варианты.
  1. Tuki_Tip
    11.10.2022 12:32
    #24809426
    В целом, я с Вами согласен. Возможны варианты. Но тут уже виднеется территория противостояния двух философий или отношений к своей профессии. На одной стороне люди, которые "лишь бы платили", а с другой полноправные участники бизнеса. А разработчик это полноправный участник бизнеса (по Мартину). И если я ответственный участник этих процессов, то стратегию я строю для себя, а не для нанимателя. Нанемателю, т.е. бизнесу, в подовляющем большенстве случаев(возможно ошибаюсь), глубоко плевать на структуру и архитектуру проекта, ему важно value которое приносит продукт.
    
    Поэтому, да, варианты возможны, но нужно отдавать себе отчет на чьей ты стороне)
    
    MAXH0
    11.10.2022 14:01
    #24809796
    О! " А разработчик это полноправный участник бизнеса (по Мартину)." Ссылку не дадите? Я не знаком с источником...
    
    Здравый же смысл подсказывает, что в большинстве случаев разработчик-фрилансер далек от "полноправного участника бизнеса". Даже в большинстве крупных корпораций есть специальные люди, которые следят за тем, чтобы bus factor не обрушил проект, и сохранялась взаимозаменяемость людей и преемственность архитектуры. Там тоже "полноправность" для большинства условна. А дословное следование документации просто прописано в инструкции. Для индивидуалов следование стандартам целиком лежит в поле ответственности заказчика. И, если честно, мне не очень понятно, что значит "полноценный участник бизнеса" для ИП.
    
    Tuki_Tip
    11.10.2022 14:07
    #24809816
    "Чистая архитектура" стр. 39. "Битва за архитектуру".
    
    Не сомневаюсь, что вы умеете читать между строк
    
    ЗЫ:
    Добавлю для читателей, чтобы не пришлось качать книжку
    
    Эффективные команды разработчиков часто выходят победителями в этой борьбе. Они открыто и на равных вступают в конфликт со всеми другими заинтересованными сторонами. Помните: как разработчик программного обеспечения вы тоже являетесь заинтересованной стороной. У вас есть свой интерес в программном обеспечении, который вы должны защищать. Это часть вашей роли и ваших обязанностей. И одна из основных причин, почему вас наняли.
    
    MAXH0
    11.10.2022 15:02
    #24810052
    
    Uncle Bob это про AGILE, а не про реальную жизнь
    
    Tuki_Tip
    11.10.2022 15:50
    #24810196
    Даже так? Все встало на свои места. Спасибо за дискуссию!
    
    MAXH0
    12.10.2022 10:40
    #24811880
    Не смотря на то что Вы закрыли дискуссию, я, подумав, решил уточнить, чтобы не было недосказанности:
    
    Я считаю отход от документации антипатерном. Но видел агентства, которые практиковали его. Потому что выгодно и удобно.
    
    AGILE работает в реальной жизни, тогда и только тогда когда выполняется 100500 условий. Перечисленных, например, в статье Agile без идеализма. И, главное, Agile снизу не строится. И значит утверждение " разработчик - полноправные участники бизнеса" подтверждается авторитетом Мартина, тогда и только тогда, когда отношения выстроены уже по Agile. А в реале это встречается, право, не так часто, как бы хотелось.
    
    Действительно этот холивар в этой статье про Django явно лишний. Поэтому Вам тоже "Спасибо за дискуссию"
    
    Tuki_Tip
    11.10.2022 14:13
    #24809826
    что в большинстве случаев разработчик-фрилансер далек от "полноправного участника бизнеса"
    
    противостояние происходит на разных уровнях, но поле боя одно.
    
    Даже в большинстве крупных корпораций есть специальные люди, которые следят за тем, чтобы bus factor не обрушил проект, и сохранялась взаимозаменяемость людей и преемственность архитектуры. Там тоже "полноправность" для большинства условна
    
    понятно что есть некоторая иерерхия разработчиков в крупных компаниях. Я же, во-первых, имею ввиду некий собирательный образ разработчика, во-вторых, это зависит от того, как разработчик себя позиционирует в рамках своей команды и компании в целом. Разработчик, который на стороне тех кто про "лишь бы платили" вероятно так и не выростет до того, кто, все же, принимает решения. И, вероятно, уйдет из компании фрилансить. А тех фрилансеров, которые на другой стороне, с высокой долей вероятности заберут в штат.