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

Fast jedes Django-Projekt beginnt gleich. Ein sauberes django-admin startproject, ein paar Models, schnell ein erster View, dann „nur kurz“ ein Feature.

Am Anfang fühlt sich alles leicht an. Fortschritt ist sichtbar, Dinge funktionieren schnell, und Django nimmt einem viel Arbeit ab.

Und dann, Monate oder Jahre später, kippt das Bild. Niemand möchte den Code mehr anfassen. Neue Features ziehen sich, Bugfixes erzeugen neue Probleme, und plötzlich gibt es Stellen im Code, die man besser nicht mehr berührt.

Das liegt nicht an Django. Es liegt an der Struktur, die nie bewusst entstanden ist.

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

Django ist darauf ausgelegt, Geschwindigkeit zu ermöglichen. Ein Model reicht, um sofort ein Admin-Interface zu haben. Views funktionieren ohne viel Boilerplate, und das ORM nimmt einem den direkten Umgang mit SQL ab.

Genau das wird zum Problem.

Man kann sehr lange produktiv sein, ohne sich Gedanken über Architektur zu machen. Code wächst dann organisch, aber unkontrolliert. Logik verteilt sich über das gesamte Projekt, und irgendwann ist nicht mehr klar, wo eigentlich was passiert.

Typischerweise sieht man dann genau diese Muster:

• alles landet in models.py
• Business-Logik rutscht in Views
• Validierung verteilt sich zwischen Model und Serializer
• Hilfsfunktionen verschwinden in einer utils.py

Das funktioniert erstaunlich lange. Bis es plötzlich nicht mehr funktioniert.

2. „Fat Models“ sind kein Architekturkonzept

Ein oft gehörter Ratschlag in der Django-Welt lautet: „Business-Logik gehört ins Model.“

Das klingt zunächst sinnvoll, führt aber in vielen Projekten zu einem anderen Extrem.

Models wachsen immer weiter, sammeln Verantwortung und werden zum zentralen Ort für alles. Irgendwann enthalten sie nicht nur Daten und einfache Regeln, sondern auch komplexe Abläufe, externe Abhängigkeiten und implizite Seiteneffekte.

Das Ergebnis sind Modelle, die niemand mehr wirklich versteht. Änderungen werden riskant, Tests werden schwierig, und der Lebenszyklus der Daten ist kaum noch nachvollziehbar.

Ein Model ist kein Domain-Service. Wenn es sich so verhält, ist die Architektur bereits aus dem Gleichgewicht geraten.

3. Views werden zu Mini-Applikationen

Viele Views beginnen harmlos:

def create_order(request):
    ...

Mit der Zeit wächst diese Funktion. Erst kommt Validierung hinzu, dann Berechtigungen, später Transaktionen, Logging, Sonderfälle und vielleicht noch Feature-Flags.

Am Ende ist die View nicht mehr nur Einstiegspunkt, sondern eine kleine Applikation für sich.

Das Problem dabei ist grundlegend. Views sollten koordinieren, nicht entscheiden. Sobald Logik direkt in der View entsteht, ist sie fest an HTTP gebunden. Damit wird sie schwer testbar, schwer wiederverwendbar und schwer zu verändern.

4. Fehlende Trennung von Domain und Infrastruktur

In vielen unwartbaren Projekten ist die Grenze zwischen Fachlogik und Technik praktisch nicht vorhanden.

Datenbankzugriffe tauchen überall auf, externe APIs werden direkt in Views aufgerufen, und globale Settings bestimmen das Verhalten an vielen Stellen gleichzeitig. Ein klarer Kern der Anwendung ist nicht erkennbar.

Das hat konkrete Folgen. Tests benötigen fast immer eine echte Datenbank, Fixtures werden komplex, und jede Änderung fühlt sich riskant an. Refactoring wird vermieden, weil niemand sicher sagen kann, was alles betroffen ist.

Ohne saubere Trennung von Schichten gibt es keinen sicheren Weg, ein System umzubauen.

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

Viele Teams verschieben Tests auf später. In der Praxis bedeutet das oft: sie kommen gar nicht oder in einer Form, die wenig hilft.

Statt klarer, gezielter Tests entstehen große Integrationstests mit komplexen Datenstrukturen. Diese Tests sind langsam, fragil und geben wenig Vertrauen.

Das eigentliche Problem ist nicht die Menge der Tests, sondern ihr Fokus. Ohne früh definierte Grenzen ist unklar, was stabil sein soll und was sich ändern darf.

Am Ende fehlt das Vertrauen in den Code. Und genau das ist der Kern von Unwartbarkeit.

6. Django wird als Framework missverstanden

Django liefert Werkzeuge, aber keine Architektur. Es zwingt dich nicht zu klaren Schichten oder Verantwortlichkeiten.

Das ist gleichzeitig Stärke und Schwäche.

Wer Django nur als Sammlung von Views, Models und Templates nutzt, bekommt genau das zurück: ein Projekt ohne klare Struktur. Eine Ansammlung von Dateien, die zwar funktionieren, aber keinen klaren Evolutionspfad haben.

Wartbare Systeme entstehen nicht zufällig. Sie sind das Ergebnis bewusster Entscheidungen.

Was stattdessen hilft

Wartbare Django-Projekte zeichnen sich nicht durch Perfektion aus, sondern durch Klarheit.

Views bleiben dünn und übernehmen nur die Koordination. Geschäftslogik wird bewusst in eigene Services ausgelagert. Models sind klar begrenzt und tragen nur die Verantwortung, die wirklich zu ihnen gehört.

Tests konzentrieren sich auf das Verhalten der Anwendung und geben Sicherheit für Veränderungen. Die Struktur des Projekts ist so gewählt, dass Wachstum erwartet wird, nicht dass es irgendwann „passiert“.

Das Ziel ist kein perfektes System. Das Ziel ist ein System, das man noch verändern kann.

Fazit

Django ist selten das Problem. Die meisten Projekte werden unwartbar, weil sie zu lange ohne klare Struktur wachsen dürfen.

Django verzeiht viel. Aber es vergisst nichts.

Wer früh beginnt, Verantwortung sauber zu trennen, spart sich später enorme Kosten in Form von Unsicherheit, Diskussionen und aufwendigen Refactorings.