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

Waarom app-scheiding goed past bij DRF

  • 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

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

  • 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

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

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

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.