Архитектура Django приложений (теория)

Рейтинг: 1Ответов: 1Опубликовано: 04.07.2023

По теории в Джанго разный бизнес-функционал одного проекта стоит разносить по отдельным аппам. Это позволит переиспользовать эти аппы в других проектах. Но что делать, если у нас app1 и app2 используют (или должны использовать) одну модель данных?

Если описывать модель только в app1 и импортировать ее в app2, то получается связанность функционала. Что на мой взгляд разрушает идею аппов. Если описать модель в каждом аппе, то при миграции будет соответственно создано две таблицы в БД.

Резонный вопрос, а правильная ли вообще такая архитектура приложения, когда связанность происходит либо на стороне БД, либо на стороне кода?

Приведу пример на сейте booking.com:

  1. Есть booking.com где физ.лицо может просматривать гостиницы и их бронировать
  2. Есть admin.booking.com где юр.лицо может регистрировать гостиницу

И там и там должна быть условная модель Hotels, в которой будут храниться гостиницы.

Если переложить такую модель на Джанго, то вижу, что это должны быть либо два отдельных проекта со своими БД. Между БД настраивается репликация данных. Либо это должны быть два разных аппа имеющих одну общую модель, но как ее тогда правильнее реализовывать?

И собственно основной вопрос: как правильно строить архитектуру приложения для подобных случаев?

Если ответ на вопрос длинный,то буду рад ссылкам или книгам, где это описано. Самому не удалось найти.

django архитектура
Источник: Stack Overflow на русском

Ответы

▲ 1Принят

Один из возможных путей решения этой проблемы:

  1. Создать отдельное приложение и назвать его, например, core
  2. В этом приложение описать "похожие" модели. Чтобы это удобно сделать сначала можно создать абстрактную модель, в Django для этого нужно добавить к классу модели
class Meta:
    abstract = True

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

  1. Получившиеся базовые модели импортировать в необходимые приложения и использовать

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