Services in Django: Saubere Trennung von Logik und Struktur

Ein häufiger Ausweg aus dieser Situation ist der Einsatz von sogenannten Services. Dabei handelt es sich nicht um ein spezielles Django-Feature, sondern um ein Architekturprinzip. Die Idee ist einfach: Geschäftslogik gehört weder in Views noch in Models, sondern in eine eigene, klar abgegrenzte Schicht.

---

Was ist ein Service?

Ein Service ist eine Funktion oder Klasse, die eine klar definierte fachliche Aufgabe übernimmt. Typische Beispiele sind das Erstellen einer Bestellung, das Registrieren eines Benutzers oder das Verarbeiten einer Zahlung. Ein Service kapselt dabei alle notwendigen Schritte und sorgt dafür, dass diese konsistent und nachvollziehbar ausgeführt werden.

Wichtig ist, dass ein Service unabhängig von der Umgebung ist, in der er aufgerufen wird. Ob die Logik über eine Web-View, eine API oder einen Hintergrundprozess gestartet wird, spielt keine Rolle. Der Service bleibt immer gleich.

---

Warum Services statt Business-Logik in Views und Models?

In vielen Projekten landet Logik an den Stellen, an denen sie zuerst gebraucht wird. Da Requests in Views ankommen, entsteht dort schnell Logik. Gleichzeitig wird oft empfohlen, Geschäftslogik in Models zu platzieren, was ebenfalls dazu führt, dass sich dort immer mehr Verantwortung ansammelt.

Beide Ansätze funktionieren kurzfristig, führen aber langfristig zu Problemen. Die Struktur des Projekts wird unklar, und Änderungen werden riskanter.

---

Views werden zu komplex

Views starten häufig sehr einfach. Sie nehmen einen Request entgegen und geben eine Response zurück. Mit der Zeit wächst jedoch der Funktionsumfang. Es kommen Validierung, Berechtigungsprüfungen, Datenbankoperationen und Sonderfälle hinzu.

Das führt dazu, dass Views immer größer und schwerer verständlich werden. Statt nur den Ablauf zu steuern, enthalten sie plötzlich einen Großteil der eigentlichen Geschäftslogik. Dadurch werden sie schwer testbar und kaum wiederverwendbar.

---

Models werden überladen

In vielen Django-Projekten werden Models mit der Zeit immer umfangreicher, weil dort zunehmend Logik untergebracht wird, die eigentlich nicht dorthin gehört. Neben der reinen Datenstruktur finden sich plötzlich externe API-Aufrufe, komplexe Geschäftsregeln oder sogar Seiteneffekte, die beim Speichern eines Objekts ausgelöst werden.

Das führt dazu, dass Models ihre eigentliche Aufgabe verlieren. Statt einfache, klar definierte Datenstrukturen zu sein, entwickeln sie sich zu schwer verständlichen Klassen, in denen viele verschiedene Verantwortlichkeiten vermischt sind. Änderungen an einer Stelle können unerwartete Auswirkungen an anderer Stelle haben, weil Abhängigkeiten nicht mehr offensichtlich sind.

Zusätzlich wird die Testbarkeit deutlich schlechter. Wenn ein Model externe Systeme anspricht oder implizite Logik beim Speichern ausführt, wird es schwierig, isolierte und zuverlässige Tests zu schreiben. In der Praxis führt das oft dazu, dass entweder gar nicht getestet wird oder Tests sehr komplex und fehleranfällig werden.

---

Typische Probleme ohne Services

Wenn keine klare Trennung der Verantwortlichkeiten existiert, entstehen typische Muster. Logik verteilt sich über mehrere Dateien, und es ist nicht mehr klar ersichtlich, wo bestimmte Entscheidungen getroffen werden. Änderungen führen häufiger zu Seiteneffekten, weil Abhängigkeiten implizit sind.

In solchen Projekten steigt die Komplexität kontinuierlich. Neue Features dauern länger, Fehler sind schwerer zu beheben, und das Vertrauen in den Code sinkt.

---

Grundidee des Service Layers

Die Einführung eines Service Layers bringt Struktur in diese Situation. Die Anwendung wird in klare Bereiche aufgeteilt: Models kümmern sich um die Datenstruktur, Services enthalten die Geschäftslogik, und Views orchestrieren den Ablauf.

Diese Trennung sorgt dafür, dass jede Schicht eine klar definierte Aufgabe hat. Dadurch wird der Code verständlicher und leichter wartbar.

---

Trennung von Daten, Logik und HTTP

Ein zentraler Vorteil von Services ist ihre Unabhängigkeit von HTTP. Ein Service kennt keine Requests, keine Templates und keine Serialisierung. Er arbeitet ausschließlich mit Daten und gibt Ergebnisse zurück.

Dadurch kann die gleiche Logik in unterschiedlichen Kontexten verwendet werden. Eine Funktion, die in einer View genutzt wird, kann genauso in einem Celery-Task oder einem Skript eingesetzt werden.

---

Einfache Beispielstruktur

Eine mögliche Struktur innerhalb einer App könnte so aussehen:

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

In dieser Struktur bleiben die Verantwortlichkeiten klar getrennt. Models definieren die Daten, Services enthalten die Logik, Selectors kümmern sich um komplexe Abfragen, und Views steuern den Ablauf.

---

services.py einführen

Ein einfacher Service kann als Funktion implementiert werden. Wichtig ist, dass er eine klar definierte Aufgabe erfüllt und keine unnötigen Abhängigkeiten hat.

def create_order(user: User, items: list[Item]) -> Order:
    order = Order.objects.create(user=user)

    for item in items:
        OrderItem.objects.create(
            order=order,
            product=item["product"],
            quantity=item["quantity"],
        )

    return order

Dieser Service kapselt die gesamte Logik zur Erstellung einer Bestellung und kann unabhängig vom Kontext verwendet werden.

---

Aufteilung in create, update, delete

In der Praxis ist es sinnvoll, Services entlang klarer Operationen zu strukturieren. Typische Funktionen sind das Erstellen, Aktualisieren oder Löschen von Objekten.

Diese klare Benennung erleichtert das Verständnis und sorgt dafür, dass Entwickler schnell die richtige Stelle im Code finden.

---

Beispiel: Business-Logik aus der View auslagern

Ohne Services enthält eine View häufig die gesamte Logik:

def create_order(request):
    user = request.user
    items = request.POST.get("items")

    order = Order.objects.create(user=user)

    for item in items:
        OrderItem.objects.create(
            order=order,
            product=item["product"],
            quantity=item["quantity"],
        )

    return redirect("order_success")

Nach der Einführung eines Services wird die View deutlich einfacher:

def create_order(request):
    order = create_order_service(
        user=request.user,
        items=request.POST.get("items"),
    )

    return redirect("order_success")

Die View übernimmt nur noch die Steuerung, während die eigentliche Logik im Service liegt.

---

Zusammenspiel mit Models

Models sollten sich auf ihre Kernaufgabe konzentrieren. Sie definieren die Struktur der Daten und enthalten einfache Regeln wie Validierung oder kleine Hilfsmethoden.

Komplexe Abläufe, die mehrere Schritte oder externe Systeme betreffen, gehören nicht ins Model. Diese Logik ist im Service besser aufgehoben.

---

Was gehört ins Model, was in den Service?

Models sind für die Beschreibung von Daten zuständig. Sie definieren Felder, Beziehungen und einfache Regeln. Services hingegen kümmern sich um Abläufe und Prozesse.

Sobald mehrere Schritte koordiniert werden müssen oder unterschiedliche Komponenten zusammenarbeiten, ist ein Service die richtige Wahl.

---

Zusammenspiel mit Views

Views sollten möglichst schlank bleiben. Ihre Aufgabe besteht darin, den Request entgegenzunehmen, den passenden Service aufzurufen und eine Response zurückzugeben.

Diese klare Struktur macht Views leicht verständlich und flexibel. Eine Änderung im Service erfordert keine Anpassung an der View, solange die Schnittstelle gleich bleibt.

---

Views als Orchestrierer

Eine gut strukturierte View enthält nur wenig Logik und ist leicht zu überblicken:

def create_order(request):
    order = create_order(user=request.user, items=request.data)
    return JsonResponse({"order_id": order.id})

Der Ablauf ist klar erkennbar, und die eigentliche Logik liegt an einer zentralen Stelle.

---

Tests für Services

Ein großer Vorteil von Services ist ihre gute Testbarkeit. Da sie unabhängig von HTTP sind, lassen sie sich isoliert testen.

def test_create_order():
    user = UserFactory()
    items = [{"product": ProductFactory(), "quantity": 2}]

    order = create_order(user=user, items=items)

    assert order.items.count() == 1

Solche Tests sind schnell, stabil und einfach verständlich.

---

Warum Services leichter testbar sind

Da Services keine Abhängigkeiten zu HTTP oder Templates haben, können sie ohne komplexe Setup-Schritte getestet werden. Es sind keine Requests oder Response-Objekte notwendig, und die Tests konzentrieren sich ausschließlich auf die fachliche Logik.

Das führt zu einer besseren Testabdeckung und erhöht das Vertrauen in den Code.

---

Typische Fehler

Auch beim Einsatz von Services können Probleme entstehen. Ein häufiger Fehler ist, dass Services zu groß werden und zu viele Aufgaben gleichzeitig übernehmen. Dadurch entsteht erneut Komplexität, nur an einer anderen Stelle.

Ein weiteres Problem sind versteckte Datenbankzugriffe. Wenn nicht klar ist, welche Queries ein Service ausführt, wird Debugging schwierig und Performance leidet.

---

Fazit

Services sind kein zwingender Bestandteil von Django, aber sie sind ein wirkungsvolles Mittel, um Struktur in wachsende Projekte zu bringen. Sie helfen dabei, Logik klar zu organisieren, Verantwortlichkeiten zu trennen und den Code besser wartbar zu machen.

Ein gut strukturiertes Django-Projekt erkennt man oft daran, dass die Geschäftslogik an einer zentralen, klar definierten Stelle liegt. Genau diese Rolle übernehmen Services.