Лучшая практика для разделения проекта django на приложения

Question

Я хочу знать, как разделить проект, имеющий иерархическую структуру, на приложения. Допустим, я пытаюсь создать что-то вроде github.com, например. На github.com учетная запись имеет несколько репозиториев, которые имеют некоторые функции, такие как код, проблемы или запросы извлечения. И эти функции имеют ссылки на другие функции. В таком случае, какое приложение, а какое нет? В то время я должен помещать приложения в корневой каталог или в каталог приложений в качестве вложенных приложений?

Answer 1

В идеальном мире каждое приложение будет независимым от других или только слабо связанным с другими. Но во многих реальных ситуациях часто бывают такие взаимозависимости, что вряд ли стоит пытаться их абстрагировать.

Итак, тогда, в этом случае... лучший способ разделить их - это разделить их на функциональные группы, где большинство представлений, моделей и т. Д. В каждом приложении используются исключительно в приложении. Итак, учитывая ваш пример с github, "проблемами" может быть их собственное приложение. issues Приложение будет иметь конкретные представления, которые связаны исключительно с отображением, редактированием и обслуживанием (ajax-запросов и т. д.) проблем, моделей для хранения проблем и их текущего состояния, шаблонов, которые несут единоличную ответственность за отображение представлений проблем, например, за ввод проблем, за проблемы для каждого пользователя., вопросы по проекту, детали конкретных вопросов. Там на самом деле много проблемного кода.

И да, к тому времени, как вы закончите, у вас будут, например, внешние ключи от этих моделей проблем к пользовательским моделям и, возможно, к модели фиксации, модели проекта... много взаимозависимостей, которые могут помешать issues приложение от работы без присутствия других приложений. Но, по логике вещей, когда придет время поработать над проблемой системы, вы будете знать, куда идти.. потому что весь код проблемы находится в одном месте. Все настройки выпуска по умолчанию находятся в issues/settings.py например, все таблицы, в основном связанные с проблемами, будут иметь префикс app_label например. issues_issue, issues_comment.. так далее..

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

В некоторых случаях вы можете реализовать необязательные зависимости, например... когда что-то происходит в приложении A, Model_A, это должно инициировать что-то, происходящее в приложении B, Model_B... но только если приложение B установлено. Есть способы сделать это менее тесно связанное поведение, такое как сигнальная система Джанго

https://docs.djangoproject.com/en/2.0/ref/signals/

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

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

Answer 2

Я бы поместил приложения на уровне вашего файла manage.py в ваш основной проект, тогда вы можете легко запустить эту команду: python manage.py startapp login_app. Тогда вы можете иметь такую ​​структуру:

main_project
     login_app
     codeissues_app
     pullrequests_app

Answer 3

Невозможно создать независимые приложения для каждого приложения в вашем проекте. Я предлагаю вам следовать domain driven design, (погугли это)

Итак, представьте, что вы строите интернет-магазин. Вы бы хотели что-то вроде:

your_project_folder
   docs
   readme
   static
   your_project
        domain # here you put the models logic
            cart
            products
            payment
            shipping
            tax
        infrastructure # your packages to interface with other services
            paypal
            stripe
        interface 
            rest
            another_rest
        presentation
            public_site
   ...

Это всего лишь пример того, как вы можете разделить проект. Чем ты должен иметь границы. В папке домена вы должны сгруппировать пакеты (и, соответственно, разработать свою модель), чтобы запретить перекрестные ссылки.

Интерфейс, инфраструктура и представление могут получить доступ к домену.

Домен должен быть более строгим. Посмотрите здесь: https://martinfowler.com/bliki/BoundedContext.html

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