Wichtige Erkenntnisse:
- Eine Django App ist mehr als nur eine Ordnerstruktur.
- Sie ist weniger eine Bereitstellungseinheit, sondern vielmehr eine Einheit zur Trennung von Geschäftsdomänen.
- Bei DRF verhalten sie sich wie Module für spezifische API-Funktionen, was ihre Vorteile deutlich macht.
- In regulären Django-Webanwendungen mag der Bedarf anfangs weniger offensichtlich sein.
- Doch mit zunehmender Projektgröße werden die Unterschiede im Management von Modellen, Admin-Oberflächen, Tests und Migrationen immer deutlicher.
- Eine gut konzipierte App wird zu einem wiederverwendbaren Asset, das später in andere Projekte übertragen werden kann.

Auch wenn ein Django-Projekt auf einem einzigen Server bereitgestellt wird, lassen sich mit startapp mehrere Apps erstellen und aufteilen. Diese Struktur ist besonders natürlich für DRF-basierte Headless API-Server, aber auch in Vorlagen-basierten Django-Webanwendungen hat die App-Aufteilung weiterhin ihre Berechtigung.

Konzeptuelles Diagramm der Django-Projektstruktur

Warum die App-Aufteilung in DRF so sinnvoll ist

  • Klare API-Grenzen

  • accounts

  • posts
  • billing

  • notifications

  • Jede App funktioniert wie ein eigenständiges API-Bündel

  • models

  • serializers
  • views / viewsets
  • permissions
  • urls

  • tests

  • Erweiterung mehrerer Funktionen auf standardisierte Weise innerhalb eines einzigen DRF-Servers

  • Unerwartete Synergien entstehen, da verschiedene Apps im selben Projekt existieren

  • Beitrag veröffentlichen → Benachrichtigung erstellen

  • Zahlungsstatus → Benutzerberechtigungen ändern
  • Benutzereinstellungen → Anzeige von Inhalten anpassen

Bedenken bei der App-Aufteilung in regulären Django-Webanwendungen

In einer Vorlagen-basierten Django-Webanwendung führen die aufgeteilten Apps letztendlich zu:

  • Ausführung auf demselben Server
  • Verwendung derselben Datenbank
  • Teilen derselben Einstellungen
  • Gebündelt in derselben Bereitstellungseinheit
  • Template-Flüsse können sich leicht vermischen

Daher kann sich bei kleineren Webanwendungen die Frage stellen: „Muss ich wirklich Apps aufteilen?“

Warum Apps trotzdem aufgeteilt werden sollten

  • Verhindert, dass Modelle zu groß werden
  • Admin-Oberflächen sind domänenbasiert organisiert
  • Migration-Historie wird pro App getrennt
  • Erleichtert das Testen spezifischer Apps
  • Fördert ein bewusstes Import-Struktur-Design und hilft, Spaghetti-Code zu vermeiden
  • Grenzen sind bereits vorhanden, falls Funktionen später getrennt oder als API bereitgestellt werden sollen

Apps können zu wiederverwendbaren Komponenten werden

Die App-Struktur von Django ermöglicht es, Funktionen wie Plug-and-Play-Komponenten zu gestalten.

Selbst Apps, die innerhalb eines Projekts entwickelt wurden, lassen sich bei guter Strukturierung leicht in andere Projekte übertragen.

Zum Beispiel:

  • Benachrichtigungsfunktion → notifications
  • Tag-Funktion → tags
  • Zahlungsfunktion → billing

Solche unabhängig entwickelten Apps können in zukünftigen Projekten wie folgt wiederverwendet werden:

  • App-Ordner kopieren
  • Zu INSTALLED_APPS hinzufügen
  • Erforderliche URLs verknüpfen
  • Migrationen ausführen
  • Templates oder Einstellungen an das Projekt anpassen

Bekannte Bibliotheken im Django-Ökosystem werden ebenfalls auf diese Weise bereitgestellt.

  • django-allauth: Bietet Registrierungs-, Anmelde- und Social-Login-Funktionen als App.

  • django-taggit: Bietet eine Tag-Funktion als wiederverwendbare App.

  • django-tailwind: Integriert die Tailwind-Entwicklungsumgebung als App in ein Django-Projekt.

Das heißt, eine Django App ist nicht nur „ein Ordner in meinem Projekt“, sondern kann bei guter Gestaltung zu einem funktionalen Asset werden, das auch in anderen Projekten wiederverwendbar ist.

Kriterien für eine sinnvolle App-Aufteilung

Anzeichen, dass eine App aufgeteilt werden sollte:

  • Es gibt ein unabhängiges Datenmodell.
  • Eine separate Admin-Gruppe ist erforderlich.
  • Es gibt eine eigene Geschäftslogik.
  • Tests sollen separat ausgeführt werden.
  • Es besteht die Möglichkeit, dass sie später als API oder separater Dienst ausgelagert wird.
  • Der Funktionsname beschreibt eine Service-Domäne.
  • Es besteht die Möglichkeit der Wiederverwendung in anderen Projekten.

Beispiele:

  • accounts
  • billing
  • notifications
  • support
  • analytics

Fazit

Die Aufteilung von Apps in einem Django-Projekt ist:

Eine Struktur, die die Komplexität in für Menschen verständliche Einheiten unterteilt, wenn das Projekt wächst.

Und geht man noch einen Schritt weiter, ist es:

Ein Django-typisches Modulsystem, das wiederverwendbare Funktionen als Assets etabliert.

Bei DRF treten diese Vorteile sofort zutage, da sie gut zu den API-Grenzen passen, während in regulären Django-Webanwendungen ihr Wert dazu neigt, sich erst zu zeigen, wenn das Projekt wächst oder man beginnt, mehrere Projekte zu entwickeln.