Django Backend architecture for multiple projects with shared class models

Masoud Taee 0
Viewed 43

We are using Django to develop our product. Our product contains 5 Django projects. Each project uses 50 shared class Models and models are in the developing process.

There are two possible ways to handle all these related projects with models in the development and production process:

One possible solution is to use models in one project with all migration files and use them in other projects with managed=False in the Django class model. But the problem with this structure is:

  1. Each change in original models must apply to other projects
  2. This approach makes the production process repeatedly and hard to manage properly
  3. New features in each project are connected to model changes
  4. By adding new required fields to an existing model, other projects that create new instances from the updated model would face rational problems. Even if they don't use these new fields

The other possible solution is gathering all projects as one project with the below diagram:

Diagram

Now this configuration's problem is:

  1. Complicated deploying production
  2. Complicated to route the project
  3. All deployed services should redeploy with every change in one model
  4. All of the projects are in one place

My question is:
Whether the suggested solutions are correct or then What is the best and optimum architecture to handle all of
the projects which work correctly deploy on separate VM machines?

PS: All projects may use the new changes in models as their new features.

PS2: Each project and databases will be deployed on separate Host.

model django
1 Answers

Other than the term project, Django also has a term called application. The documentation mentions:

The term application describes a Python package that provides some set of features. Applications may be reused in various projects.

Given that you have multiple projects and these projects may have shared models, it's only logical to make reusable apps that will encapsulate certain functionality including models.

From what I understand these projects will share a database where the corresponding tables for the models will be. Since Django maintains the state of the migrations in a database table, it is not an issue for an app to be used in multiple projects, and the migration for an app won't end up being applied multiple times.

Hence I suggest you to have reusable apps that encapsulate certain functionalities and use these apps in you projects through the INSTALLED_APPS setting. For example you build a reusable app foo_users and all of your projects need to use the models inside it, then you just need to add foo_users to the INSTALLED_APPS setting of all your projects:

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

One of the concerns with following such an architecture though is the level of coupling between your project and the application. It might happen that a model field is removed from an application but a project still uses it, breaking that project. Hence the application needs to expose an API to the project which allows loose coupling between the app and the project the project needs to use this API rather than utilizing app's lower level features directly.

Abdul Aziz Barkat0
Related