Архитектура Django Backend для нескольких проектов с общими моделями классов

Мы используем Django для разработки нашего продукта. Наш продукт содержит 5 проектов Django. Каждый проект использует 50 общих классов Models и модели находятся в процессе разработки.

Существует два возможных способа обработки всех этих связанных проектов с моделями в процессе разработки и производства:

Одним из возможных решений является использование моделей в одном проекте со всеми файлами миграции и использование их в других проектах с managed=False в модели класса Django. Но проблема с такой структурой заключается в следующем:

  1. Каждое изменение в исходных моделях должно применяться к другим проектам
    2. .
  2. Такой подход делает производственный процесс многократным и трудно управляемым должным образом
  3. Новые возможности в каждом проекте связаны с изменениями моделей
  4. Добавляя новые обязательные поля в существующую модель, другие проекты, создающие новые экземпляры на основе обновленной модели, столкнутся с рациональными проблемами. Даже если они не будут использовать эти новые поля

Другим возможным решением является сбор всех проектов в один проект с приведенной ниже схемой:

Диаграмма

Теперь проблема этой конфигурации заключается в следующем:

  1. Сложное развертывание производства
  2. Сложная маршрутизация проекта
  3. Все развернутые сервисы должны переразвертываться при каждом изменении в одной модели
  4. Все проекты находятся в одном месте

Мой вопрос заключается в следующем:
Являются ли предложенные решения правильными или тогда Какова лучшая и оптимальная архитектура для обработки всех
проектов, которые корректно работают, развернутые на отдельных виртуальных машинах?

PS: Все проекты могут использовать новые изменения в моделях в качестве своих новых возможностей.

Кроме термина project, в Django также есть термин application. В документации упоминается:

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

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

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

Следовательно, я предлагаю вам иметь многоразовые приложения, которые инкапсулируют определенные функциональные возможности, и использовать эти приложения в ваших проектах с помощью настройки INSTALLED_APPS. Например, вы создаете многоразовое приложение foo_users и все ваши проекты должны использовать модели внутри него, тогда вам просто нужно добавить foo_users в настройку INSTALLED_APPS всех ваших проектов:

INSTALLED_APPS = [
    ...
    'foo_users.apps.FooUsersConfig',
    ...
]

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

Вернуться на верх