Résumé des points clés :
- Une application Django n'est pas qu'une simple séparation de dossiers.
- Ce n'est pas une unité de déploiement, mais plutôt une unité de séparation par domaine métier.
- Dans DRF, elle fonctionne comme un module par fonctionnalité API, ce qui rend ses avantages évidents.
- Dans une application web Django classique, la nécessité peut être moins ressentie au début.
- Cependant, à mesure que le projet grandit, la différence devient significative dans la gestion des modèles, de l'Admin, des tests et des migrations.
- Une application bien conçue devient un actif réutilisable qui peut être transféré à d'autres projets par la suite.

Même si un projet Django est déployé sur un seul serveur, il est possible de le diviser en plusieurs applications grâce à startapp. Cette structure est particulièrement naturelle pour un serveur API Headless basé sur DRF, mais la séparation des applications reste pertinente même pour une application web Django basée sur des templates.

Diagramme conceptuel de la structure d'un projet Django

Pourquoi la séparation des applications est-elle bien adaptée à DRF ?

  • Les limites de l'API sont claires.

  • accounts

  • posts
  • billing

  • notifications

  • Chaque application fonctionne comme un ensemble d'API indépendant :

  • models

  • serializers
  • views / viewsets
  • permissions
  • urls

  • tests

  • Possibilité d'étendre plusieurs fonctionnalités de manière standard au sein d'un même serveur DRF.

  • Des synergies inattendues peuvent émerger lorsque différentes applications coexistent au sein du même projet :

  • Publication d'un article → Création d'une notification

  • Statut de paiement → Modification des autorisations utilisateur
  • Paramètres utilisateur → Modification de la méthode d'affichage du contenu

Questions qui se posent avec une application web Django classique

Dans une application web Django basée sur des templates, même en séparant les applications, elles finissent par :

  • S'exécuter sur le même serveur.
  • Utiliser la même base de données.
  • Partager les mêmes paramètres (settings).
  • Être regroupées dans la même unité de déploiement.
  • Les flux de templates peuvent facilement se mélanger.

Ainsi, pour les petites applications web, on peut se demander : « Est-il vraiment nécessaire de diviser les applications ? »

Les raisons de séparer les applications, malgré tout

  • Évite que les modèles ne deviennent trop volumineux.
  • L'interface d'administration est organisée par domaine.
  • L'historique des migrations est séparé par application.
  • Facilite les tests d'une application spécifique.
  • Aide à prévenir le code spaghetti en rendant la structure d'importation plus consciente.
  • Les limites sont déjà établies si vous devez séparer ou API-iser des fonctionnalités ultérieurement.

Une application peut devenir un composant réutilisable

La structure d'application de Django permet de créer des fonctionnalités comme des composants Plug-and-Play. Même une application développée au sein d'un projet peut être facilement transférée à un autre projet si sa structure est bien conçue.

Par exemple :

  • Fonctionnalité de notification → notifications
  • Fonctionnalité de tag → tags
  • Fonctionnalité de paiement → billing

En développant ces applications de manière indépendante, vous pouvez les réutiliser dans un projet futur comme suit :

  • Copier le dossier de l'application.
  • L'ajouter à INSTALLED_APPS.
  • Connecter les URLs nécessaires.
  • Exécuter les migrations.
  • Ajuster les templates ou les paramètres (settings) selon les besoins du projet.

Les célèbres bibliothèques de l'écosystème Django sont également fournies de cette manière.

  • django-allauth : Fournit les fonctionnalités d'inscription, de connexion et de connexion sociale sous forme d'application.

  • django-taggit : Offre une fonctionnalité de tags sous forme d'application réutilisable.

  • django-tailwind : Intègre l'environnement de développement Tailwind dans un projet Django sous forme d'application.

En d'autres termes, une application Django n'est pas simplement « un dossier au sein de mon projet », mais peut devenir un actif fonctionnel réutilisable dans d'autres projets si elle est bien conçue.

Critères d'une bonne séparation

Signes indiquant qu'une application devrait être séparée :

  • Possède un modèle de données indépendant.
  • Nécessite un groupe d'administration distinct.
  • Possède sa propre logique métier.
  • Souhaite exécuter des tests séparément.
  • Est susceptible d'être séparée en API ou en service distinct ultérieurement.
  • Le nom de la fonctionnalité est explicable par un domaine de service.
  • Est susceptible d'être réutilisée dans d'autres projets.

Exemples :

  • accounts
  • billing
  • notifications
  • support
  • analytics

Conclusion

La distinction des applications dans un projet Django est :

Une structure qui permet de gérer la complexité en la divisant en unités compréhensibles par l'humain lorsque le projet grandit.

Et, allant un peu plus loin, c'est :

Un système de modules à la Django qui permet de transformer des fonctionnalités réutilisables en actifs.

Dans DRF, cet avantage est immédiatement évident car il correspond bien aux limites de l'API. Dans une application web Django classique, sa valeur a tendance à se révéler lorsque le projet s'agrandit ou que l'on commence à créer plusieurs projets.