> **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](/media/whitedec/blog_img/fc8aa3e622234c4689779c58a2b8b32e.webp)


## Pourquoi la séparation des applications est-elle bien adaptée à DRF ? {#sec-f9d183702e4a}

* 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 {#sec-5b615e36b016}

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 {#sec-ba9a6a819246}

* É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 {#sec-0f9d2f3a0f0a}

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 {#sec-638181ef3b61}

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 {#sec-85c066cfb297}

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.