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


## Warum die App-Aufteilung in DRF so sinnvoll ist {#sec-f9d183702e4a}

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

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

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

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

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

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.