Was lerne ich in diesem Kurs?

Ein praxisnaher Blick darauf, wie Django-Projekte strukturiert sein müssen, um auch nach Jahren noch verständlich, testbar und erweiterbar zu bleiben.

Wie ein wartbares Django-Projekt wirklich aufgebaut ist

Viele Django-Projekte scheitern nicht an Features, sondern an ihrer eigenen Struktur.
Nicht, weil Django ungeeignet wäre – sondern weil Wartbarkeit selten bewusst geplant wird.

Ein wartbares Django-Projekt entsteht nicht durch „Best Practices“-Listen,
sondern durch klare Verantwortlichkeiten und eine Struktur, die Veränderung erwartet.

1. Views sind Orchestrierer, keine Denker

Eine wartbare Django-View macht idealerweise nur drei Dinge:

• Request entgegennehmen
• Domain-Logik aufrufen
• Response zurückgeben

Alles andere gehört dort nicht hin.

Das bedeutet konkret:

• keine Geschäftsregeln in Views
• keine komplexen Entscheidungen
• keine versteckten Seiteneffekte

Je dünner die View, desto leichter ist:

• Testbarkeit
• Wiederverwendung
• spätere Umstellung (z. B. von HTML auf API)

2. Business-Logik gehört in Services, nicht in Models

Models sind Daten + einfache Regeln.
Nicht mehr.

Ein wartbares Projekt trennt:

• Datenstruktur (Model)
• Geschäftslogik (Service)
• Infrastruktur (ORM, HTTP, APIs)

Typisch:

orders/
├── models.py
├── services.py
├── selectors.py
├── views.py

Services:

• enthalten die eigentliche Logik
• sind unabhängig von HTTP
• können isoliert getestet werden

Models bleiben klein.
Services tragen die Verantwortung.

3. Explizite Schichten statt impliziter Magie

Unwartbare Projekte leben von implizitem Wissen:

• „Das wird automatisch gesetzt“
• „Das passiert beim Save“
• „Das ist schon immer so“

Wartbare Projekte sind explizit:

• klare Funktionsaufrufe
• sichtbare Abhängigkeiten
• nachvollziehbare Datenflüsse

Wenn man den Code lesen muss, um zu wissen, was passiert, ist das gut.
Wenn man ihn auswendig kennen muss, ist es schlecht.

4. Queries gehören an einen Ort

ORM-Zugriffe überall im Code sind Gift für Wartbarkeit.

Bewährt hat sich:

• alle komplexen Queries in sogenannten Selectors
• keine Query-Logik in Views
• keine versteckten Datenbankzugriffe in Services

Vorteile:

• bessere Übersicht
• gezieltere Optimierung
• einfacheres Refactoring

Die Datenbank ist Infrastruktur, nicht Geschäftslogik.

5. Tests testen Verhalten, nicht Implementierung

Wartbare Projekte testen:

• was das System leisten soll
• nicht, wie es intern gebaut ist

Das heißt:

• Tests auf Service-Ebene
• möglichst wenig Abhängigkeit zur Datenbank
• klare, verständliche Testnamen

Wenn Tests nur grün werden, aber niemand ihnen vertraut, sind sie wertlos.
Gute Tests geben Sicherheit für Veränderung.

6. Projektstruktur folgt Verantwortung, nicht Django-Konventionen

Django gibt Startpunkte vor – keine Architektur.

Ein wartbares Projekt:

• organisiert Code nach Domänen, nicht nach Dateitypen
• vermeidet globale utils.py
• trennt App-Grenzen bewusst

Weniger Apps, dafür klarere.
Weniger Magie, dafür mehr Absicht.

7. Wachstum ist eingeplant

Das wichtigste Merkmal wartbarer Projekte: Sie gehen davon aus, dass sie größer werden.

Das äußert sich in:

• klaren Schnittstellen
• bewusstem Umgang mit Abhängigkeiten
• Bereitschaft zu Refactoring

Nicht alles muss perfekt sein.
Aber nichts sollte zufällig sein.

Fazit

Ein wartbares Django-Projekt ist kein Kunstwerk.
Es ist ein System, das Veränderung aushält.

Django hilft dir, schnell zu starten.
Wartbarkeit beginnt dort, wo du bewusst langsamer wirst –
und anfängst, Verantwortung klar zu verteilen.