Backend-Refactoring: Schichten, Boundaries, Tests.
Backend-Refactoring: Schichten, Boundaries, Tests
Ein sauberes Backend ist nicht das, das keine Bugs hat. Es ist das, in dem Bugs leicht zu finden sind.
Was Backend-Refactoring meistens bedeutet
In Symfony/PHP-Projekten sieht der Ausgangs-Zustand oft so aus: Fat Controller, die direkt auf die Datenbank zugreifen. Business-Logik, die in Twig-Templates steckt. Services, die 15 Dependencies haben. Events, die nirgendwo dokumentiert sind.
Das ist kein Einzelfall. Das ist normales Projektwachstum ohne ausreichend Architektur-Pflege.
Das Schichten-Modell als Orientierung
Presentation Layer (Controller, API): Nimmt Anfragen entgegen, gibt Antworten zurück. Keine Business-Logik.
Application Layer (Services, Use Cases): Orchestriert Business-Logik. Kennt die Domäne, aber nicht die Datenbankstruktur.
Domain Layer (Entities, Value Objects, Domain Services): Reine Business-Logik, keine Framework-Abhängigkeiten.
Infrastructure Layer (Repositories, External Services): Konkrete Implementierungen für Datenbank, Caches, externe APIs.
Boundaries definieren
Wo hört ein Modul auf und fängt das nächste an? Was darf wer aufrufen? In Symfony: Bundle-Grenzen, Service-Tags, Event-Dispatcher. In einem Modulithen: klare Interface-Definitionen zwischen Modulen.
Wenn ein Modul direkt auf die Datenbank eines anderen Moduls zugreift – das ist eine Boundary-Verletzung. Die muss adressiert werden.
Checkliste Backend-Refactoring
Fat Controller identifiziert und Business-Logik extrahiert
Klare Schichttrennung in kritischen Bereichen
Dependencies pro Service gezählt (> 5 ist verdächtig)
Boundaries zwischen Modulen dokumentiert
Tests für refactored Bereiche vorhanden
PHPStan auf aktuellem Level grün
Backend-Architektur verbessern?
markom.digital macht Backend-Refactoring für Symfony-Projekte – mit dem Fokus auf Wartbarkeit und Testbarkeit.
