> **Belangrijkste punten:**  
> - Een Django App is meer dan alleen een aparte map  
> - Het is geen implementatie-eenheid, maar eerder een **eenheid voor het scheiden van bedrijfsdomeinen**  
> - In [[DRF]] werkt het als een module per API-functionaliteit, wat de voordelen duidelijk maakt  
> - In reguliere Django-webapps is de noodzaak aanvankelijk minder duidelijk  
> - Maar naarmate het project groeit, worden de verschillen in het beheer van modellen, Admin, tests en migraties groter  
> - Een goed ontworpen App wordt een **herbruikbaar activa** dat later naar andere projecten kan worden verplaatst  


Hoewel een [[Django]]-project vaak als één server wordt geïmplementeerd, kun je met `startapp` meerdere apps creëren.
Deze structuur is bijzonder logisch voor headless API-servers gebouwd met DRF, maar app-scheiding heeft ook nog steeds zin in template-gebaseerde Django-webapps.


![Conceptueel diagram van de Django-projectstructuur](/media/whitedec/blog_img/fc8aa3e622234c4689779c58a2b8b32e.webp)


## Waarom app-scheiding goed past bij DRF {#sec-f9d183702e4a}

* Duidelijke API-grenzen

  * `accounts`
  * `posts`
  * `billing`
  * `notifications`

* Elke app functioneert als een onafhankelijke API-bundel

  * models
  * serializers
  * views / viewsets
  * permissions
  * urls
  * tests

* Mogelijkheid om verschillende functionaliteiten op een standaardmanier uit te breiden binnen één DRF-server

* Onverwachte synergieën ontstaan doordat verschillende apps binnen hetzelfde project bestaan

  * Publicatie van berichten → generatie van meldingen
  * Betaalstatus → wijziging van gebruikersrechten
  * Gebruikersinstellingen → aanpassing van de weergave van content

## Vragen die opkomen bij reguliere Django-webapps {#sec-5b615e36b016}

In template-gebaseerde Django-webapps geldt, zelfs als je apps scheidt, uiteindelijk het volgende:

* Ze draaien op dezelfde server
* Ze gebruiken dezelfde database
* Ze delen dezelfde settings
* Ze worden gebundeld als één implementatie-eenheid
* De template-stromen kunnen ook gemakkelijk vermengen

Daarom kan bij kleine webapps de vraag rijzen: “Is het echt nodig om apps te scheiden?”

## Waarom apps toch scheiden {#sec-ba9a6a819246}

* Voorkomt dat modellen te groot worden
* Het Admin-scherm wordt geordend per domein
* De migratiegeschiedenis wordt per app gesplitst
* Het is gemakkelijker om specifieke apps te testen
* Stimuleert bewustzijn van de importstructuur en helpt spaghetticode te voorkomen
* Wanneer functionaliteiten later moeten worden gescheiden of als API moeten worden aangeboden, zijn de grenzen al vastgesteld

## Apps kunnen herbruikbare componenten worden {#sec-0f9d2f3a0f0a}

De app-structuur van Django maakt het mogelijk om functionaliteiten te creëren als **Plug-and-Play componenten**.

Zelfs apps die binnen een project zijn ontwikkeld, kunnen, mits goed gestructureerd, gemakkelijk naar andere projecten worden overgezet.

Bijvoorbeeld:

* Notificatiefunctie → `notifications`
* Tagging-functie → `tags`
* Betaalfunctie → `billing`

Door dergelijke apps onafhankelijk te maken, kunnen ze in het volgende project als volgt worden hergebruikt:

* Kopieer de app-map
* Voeg toe aan `INSTALLED_APPS`
* Koppel de benodigde URL's
* Voer migraties uit
* Pas alleen templates of instellingen aan naar het project

Bekende bibliotheken in het Django-ecosysteem worden ook op deze manier aangeboden.

* `django-allauth`: Biedt functionaliteiten voor registratie, login en social login aan als een app.

* `django-taggit`: Biedt tagging-functionaliteit aan als een herbruikbare app.

* `django-tailwind`: Integreert de Tailwind-ontwikkelomgeving als een app binnen een Django-project.

Met andere woorden, een Django App is niet zomaar “een map binnen mijn project”, maar kan, mits goed ontworpen, een **functioneel activa** worden dat in andere projecten opnieuw kan worden gebruikt.


## Goede scheidingscriteria {#sec-638181ef3b61}

Signalen die aangeven dat een app gescheiden moet worden:

* Er is een onafhankelijk datamodel
* Een aparte Admin-groep is vereist
* Er is eigen bedrijfslogica
* Je wilt tests afzonderlijk uitvoeren
* Er is een mogelijkheid dat het later wordt gescheiden als API of een aparte service
* De functienaam wordt beschreven door het servicedomein
* Er is een mogelijkheid tot hergebruik in andere projecten

Voorbeelden:

* `accounts`
* `billing`
* `notifications`
* `support`
* `analytics`


## Conclusie {#sec-85c066cfb297}

De scheiding van apps in een [[Django]]-project is:

> Een structuur die complexiteit opvouwt in door mensen te begrijpen eenheden wanneer een project groter wordt

En een stap verder:

> Een Django-achtig modulesysteem dat herhaalbaar te gebruiken functionaliteiten als activa beschouwt

In [[DRF]] komt dit voordeel direct naar voren omdat het goed aansluit bij de API-grenzen,
terwijl in reguliere Django-webapps de waarde ervan pas duidelijk wordt wanneer het project groeit of wanneer men begint met het creëren van meerdere projecten.