Wie strukturierst du einen Service/eine Architektur für eine große Laravel-Anwendung?

Question

Accepted Answer

Mit zunehmender Größe einer Laravel-Anwendung wird der Standard-Ansatz "fat controller / fat model" schwer zu warten. Größere Anwendungen profitieren von **zusätzlichen Architektur-Schichten** — Service-Klassen, Action-Klassen, Repositories, Form Requests und klare Domain-Organisation — um Geschäftslogik organisiert, testbar und wartbar zu halten.

## Das Problem: Logik landet an den falschen Stellen

```text
Small apps: logic in controllers and models is fine.
Large apps: controllers get bloated, models become "god objects", logic is duplicated
→ hard to test, maintain, and reason about. Extract logic into dedicated layers.
```

## Service-Klassen — kapseln Geschäftslogik

```php
<?php
// move complex business logic out of controllers into a service
class OrderService {
    public function __construct(
        private PaymentGateway $payments,
        private InventoryService $inventory,
    ) {}

public function placeOrder(User $user, array $items): Order {
        // orchestrate the business process — reusable, testable, focused
        DB::transaction(function () use ($user, $items) { /* ... */ });
    }
}

// the controller stays THIN — just delegates
public function store(StoreOrderRequest $request, OrderService $orders) {
    return $orders->placeOrder($request->user(), $request->validated());
}
```

**Service-Klassen** halten Geschäftslogik, halten Controller dünn (nur HTTP-Handling) und Modelle konzentriert auf Daten — und machen die Logik wiederverwendbar und unabhängig testbar.

## Andere nützliche Muster für große Anwendungen

```text
✓ Action classes — a single class per use-case (e.g. CreateUserAction) — very focused
✓ Form Requests — extract validation + authorization out of controllers
✓ API Resources — control response shape, separate from models
✓ Repository pattern — abstract data access behind interfaces (when you need it;
  often Eloquent suffices, so don't add it reflexively)
✓ Events/listeners — decouple side effects from core logic
✓ Domain-oriented organization — group code by feature/domain, not just by type
  (e.g. a modules/ structure) as the app grows
✓ Dependency injection + interfaces — for loose coupling and testability
```

## Die leitenden Prinzipien

```text
✓ Thin controllers (HTTP only) → services/actions (business logic) → models (data)
✓ Single Responsibility — each class does one thing
✓ Depend on abstractions (interfaces) for testability and flexibility
✗ Don't over-engineer — add layers when complexity justifies them, not prematurely
```

## Warum es wichtig ist

Zu verstehen, wie man eine große Laravel-Anwendung strukturiert, ist wichtiges Wissen auf Senior-Level, denn die Konventionen, die für kleine Anwendungen funktionieren (Logik in Controllern und Modellen), brechen im großen Maßstab zusammen — was zu überblähten Controllern, "Gott"-Modellen, duplizierter Logik und Code führt, der schwer zu testen und zu warten ist.

Die zusätzlichen Architektur-Schichten zu kennen — besonders **Service-Klassen** (Geschäftslogik kapseln, um Controller dünn und Modelle fokussiert zu halten, während Logik wiederverwendbar und testbar wird), plus Action-Klassen, Form Requests (Validierung/Authorization extrahieren), API Resources (Ausgabe kontrollieren), das Repository-Pattern (Datenzugriff abstrahieren, wenn nötig), Events (Nebenwirkungen entkoppeln), und **domain-orientierte Organisation** (nach Feature gruppieren, wenn die Anwendung wächst) — ist das, was dich befähigt, wartbare, skalierbare Anwendungen zu bauen.

Die leitenden Prinzipien wichtig: **dünne Controller → Services → Modelle** Schichtung, Single Responsibility und Abhängigkeit von Abstraktionen (Interfaces) für Testbarkeit und lockere Kopplung.

Ebenso wichtig ist das Urteilsvermögen, **nicht über-zu-engineeren** — Schichten hinzufügen, wenn Komplexität sie wirklich rechtfertigt, statt premature (Laravels Defaults sind für einfachere Anwendungen in Ordnung, und reflexartig Repositories/Abstraktionen hinzuzufügen bringt unnötige Komplexität).

Diese Architektur-Muster und die Prinzipien (und Zurückhaltung) für ihre Anwendung zu verstehen, ist wertvoll, um große, lange lebende Laravel-Anwendungen zu bauen, die wartbar, testbar und verständlich bleiben, während sie wachsen — was Entwickler unterscheidet, die skalierbare Anwendungen architektieren können, von denen, deren wachsende Anwendungen in verknoteten, schwer zu wartenden Code zusammenbrechen.

Dieses Architektur-Urteilsvermögen ist ein Merkmal von Senior-Laravel-Entwicklung und eine häufig relevante Überlegung für ernsthafte, wachsende Anwendungen.