Warum 90 % aller Django-Projekte später unwartbar werden

Was lerne ich in diesem Kurs?

Warum viele Django-Projekte anfangs schnell wachsen, aber später kaum noch sicher weiterentwickelt werden können.

Warum 90 % aller Django-Projekte später unwartbar werden

Fast jedes Django-Projekt startet gleich:
ein sauberes django-admin startproject, ein paar Models, schnell ein View, „nur kurz“ ein Feature.
Am Anfang fühlt sich alles leicht an.

Und dann – Monate oder Jahre später – traut sich niemand mehr, den Code anzufassen.

Neue Features dauern ewig.
Bugfixes brechen andere Stellen.
„Das darfst du nicht ändern, das hängt überall dran.“

Das ist kein Django-Problem.
Das ist ein Struktur-Problem.

1. Django macht es zu einfach, schnell produktiv zu sein

Django ist extrem gut darin, Geschwindigkeit zu ermöglichen: - Models + Admin = sofort nutzbar - Views ohne viel Boilerplate - ORM ohne SQL-Zwang

Das Problem:
Man kommt sehr weit, ohne über Architektur nachzudenken.

Viele Projekte wachsen so: - alles landet in models.py - Business-Logik in Views - Validierung halb im Model, halb im Serializer - Utilities irgendwo in utils.py

Am Anfang funktioniert das.
Später weiß niemand mehr, wo eigentlich was passiert.

2. „Fat Models“ sind kein Architekturkonzept

Ein klassischer Django-Rat lautet: „Business-Logik gehört ins Model.“

Das ist gut gemeint – aber gefährlich.

In vielen Projekten bedeutet das: - Models mit 1.000+ Zeilen - Methoden, die HTTP-Logik kennen - Abhängigkeiten zu externen Services - implizite Seiteneffekte beim Speichern

Das Resultat: - Models sind nicht mehr testbar - kleine Änderungen haben große Auswirkungen - niemand versteht mehr den Lebenszyklus der Daten

Model ≠ Domain-Service.

3. Views werden zu Mini-Applikationen

Viele Views starten harmlos:

def create_order(request):
    ...

Ein Jahr später:

• Validierung
• Berechtigungen
• Transaktionen
• Logging
• Sonderfälle
• Feature-Flags

Alles in einer Funktion oder Klasse.

Das Problem: Views sollten Orchestrierer sein, keine Logikzentralen. Wenn Views Entscheidungen treffen, ist die Logik an HTTP gebunden – und damit schwer wiederverwendbar.

4. Fehlende Trennung von Domain und Infrastruktur

In unwartbaren Django-Projekten ist alles miteinander vermischt:

• ORM-Queries überall
• externe APIs direkt in Views
• Settings als globale Wahrheit
• kein klarer „Kern“ der Anwendung

Das führt zu:

• Tests, die immer die Datenbank brauchen
• komplizierten Fixtures
• Angst vor Refactoring
• massiven Abhängigkeiten

Ohne klare Schichten gibt es keinen sicheren Umbau.

5. Tests kommen zu spät – oder gar nicht

Viele Teams sagen: „Wir testen später.“

Später kommt nie.

Oder es kommen:

• riesige Integrationstests
• fragile Testdaten
• Tests, die mehr kaputt machen als helfen

Ohne früh definierte Testgrenzen weiß niemand:

• was stabil sein muss
• was sich ändern darf
• was eigentlich das Systemversprechen ist

Unwartbarkeit ist oft nur fehlendes Vertrauen in den Code.

6. Django wird als Framework missverstanden

Django ist kein Architektur-Framework. Es zwingt dich zu keiner Struktur.

Das ist Stärke und Schwäche zugleich.

Wenn man Django als „Ordner mit Views und Models“ nutzt, bekommt man genau das:

• eine Sammlung von Dateien
• ohne klare Verantwortung
• ohne Evolutionspfad

Wartbare Projekte entstehen nicht zufällig.

Was stattdessen hilft

Wartbare Django-Projekte haben meist:

• dünne Views
• explizite Service-Layer
• klar begrenzte Modelle
• bewusst platzierte Logik
• Tests auf Domain-Ebene
• eine Struktur, die Wachstum erwartet

Nicht perfekt. Aber absichtlich.

Fazit

90 % aller Django-Projekte werden nicht unwartbar, weil Django schlecht ist. Sie werden unwartbar, weil sie zu lange ohne Struktur wachsen dürfen.

Django verzeiht viel. Aber es vergisst nichts.

Wer früh über Architektur nachdenkt, spart später Monate an Chaos, Diskussionen und Rewrite-Fantasien.