Eloquente Modelle zu groß

Eloquent ist eines der produktivsten Stücke von Laravel. Es ermöglicht Ihnen, Beziehungen zu modellieren, Daten abzufragen und einen Teil des Verhaltens der Domäne auf sehr komfortable Weise auszudrücken. Dieser Komfort ist genau der Grund, warum viele Projekte beginnen, jede neue Regel im Modell zu belassen.

Auf den ersten Blick scheint es eine gute Entscheidung zu sein: Der Code ist nah an den Daten und alles geht schnell. Das Problem entsteht, wenn das Modell aufhört, eine Entität darzustellen, und beginnt, komplette Prozesse zu koordinieren. An diesem Punkt kann die Änderung einer Geschäftsregel, einer API-Antwort oder einer kritischen Abfrage dazu führen, dass eine Klasse berührt wird, die bereits zu viele Gründe für eine Änderung enthält.

Ein großes Modell ist nicht schlecht, nur weil es viele Linien hat. Es ist besorgniserregend, wenn man Beharrlichkeit, Geschäft, Präsentation, Kontext und Koordination von Nebenwirkungen miteinander verbindet. Diese Mischung verwischt die Grenze zwischen „was diese Entität ist“ und „was das System tut, wenn etwas mit dieser Entität passiert“.

Ein erstes Anzeichen besteht darin, lange Methoden zu finden, die das natürliche Verhalten des Modells nicht beschreiben. Beispielsweise Methoden, die eine vollständige Antwort für einen Endpunkt vorbereiten, Geschäftsentscheidungen mit vielen Bedingungen berechnen oder mehrere externe Modelle koordinieren. Der Name mag unschuldig klingen, aber der Inhalt gehört nicht mehr der Entität.

Auch ein Blick auf die Zielfernrohre lohnt sich. Ein kleiner, ausdrucksstarker Umfang kann sinnvoll sein. Eine Reihe von Bereichen, die bedingte Filter, Benutzerabhängigkeiten, Sichtbarkeitsregeln, Produktreihenfolge und Berechtigungslogik sammeln, beginnt sich wie ein im Modell verborgenes Abfrageobjekt zu verhalten.

Weitere häufige Anzeichen sind Accessoren und Mutatoren, die Produktentscheidungen auflösen, indirekte Abhängigkeit von Anfrage, Authentifizierung, Sitzung oder Konfiguration, innerhalb des Modells vorbereitete API-Antworten, mit Persistenz vermischte Geschäftsregeln und Tests, die nur abgedeckt werden können, indem zu viel Kontext um sie herum erstellt wird.

Mit Laravel kommen Sie schnell voran, und das ist ein echter Vorteil. In einer ersten Version kann die Annäherung der Logik an Eloquent die Reibung verringern und zur Validierung des Produkts beitragen. Das Problem besteht nicht darin, einfach anzufangen, sondern darin, die Grenzen nicht zu überprüfen, wenn das System seinen Maßstab ändert.

Viele Projekte entwickeln sich vom einfachen CRUD zum Produktionsprodukt ohne klare Anwendungsschicht. Wenn eine neue Regel erscheint, scheint das Modell der natürliche Ort zu sein, sie zu löschen, da sie bereits über Beziehungen, Attribute und Datenbankzugriff verfügt. Wenn diese Entscheidung über Monate hinweg wiederholt wird, fungiert das Modell letztendlich gleichzeitig als Dienst, Abfrageschicht, Transformator und Richtlinie.

Es handelt sich nicht um einen Fehler von Laravel. Dies ist eine normale Folge des Wachstums mit zunehmendem Lieferdruck und ohne regelmäßige technische Überprüfung. Genau aus diesem Grund ist es wichtig, das Muster zu erkennen, bevor das Modell zu einem Stück wird, das niemand anfassen möchte.

Das sichtbarste Risiko ist Langsamkeit. Jede Änderung erfordert mehr Kontextverständnis als nötig, da die Klasse keine klare Verantwortung mehr hat. Eine Anpassung einer Geschäftsregel kann sich auf eine Abfrage, eine API-Transformation oder einen asynchronen Vorgang auswirken, der sich in derselben Datei befindet.

Auch die Angst, Code zu berühren, tritt auf. Wenn ein Modell zu viel Logik konzentriert, verlässt sich das Team nicht mehr auf kleine Änderungen. Tests sind schwieriger zu schreiben, da jede Methode Persistenz, Beziehungen, Fabriken und Sekundärzustände beinhaltet. Selbst die Optimierung von Abfragen wird komplexer, da die Abfrage mit Geschäftsentscheidungen vermischt wird.

Mittelfristig führt dieses Muster zu einer Kopplung zwischen dem Modell API und den Produktregeln. Die Wiederverwendung von Logik in einem neuen Befehl, Job oder Endpunkt zwingt Sie dazu, mehr Abhängigkeiten als nötig zu laden. Technische Schulden sind stumm, da die Anwendung weiterhin funktionieren kann, aber jede Iteration mehr kostet.

Das erste Kriterium besteht darin, im Modell das wesentliche Verhalten der Entität beizubehalten: Beziehungen, Besetzungen, relevante Attribute, kleine zustandsspezifische Regeln und Methoden, die wirklich etwas beschreiben, was das Modell „ist“ oder „weiß“. Wenn die Methode einen Prozess koordiniert, gehört sie wahrscheinlich zu einer anderen Ebene.

Anwendungsfälle können in Dienste oder Aktionen extrahiert werden. Komplexe Abfragen können in Abfrageobjekten, kleineren Bereichen oder bestimmten Klassen gespeichert sein. Die Validierung HTTP sollte in Formularanfragen enthalten sein. Die Ausgabetransformation passt am besten zu API-Ressourcen. Die Autorisierung sollte an Policies oder Gates delegiert werden. Schwere oder verzögerte Prozesse gehören normalerweise zu Jobs.

Es besteht keine Notwendigkeit, eine riesige Architektur auf einmal zu erstellen. Sinnvoller ist es, mit den Bereichen zu beginnen, die die meisten Veränderungen, die meisten Fehler oder das größte Risiko aufweisen. Eine gut gewählte Absaugung reduziert die Reibung sofort; Eine Suche nach Ästhetik kann die Komplexität erhöhen, ohne die Fähigkeit zur Evolution zu verbessern.

Stellen Sie sich ein Auftragsmodell vor, das den Handelsstatus berechnet, die Nutzlast API vorbereitet, erweiterte Filter anwendet, Berechtigungen prüft und Benachrichtigungen auslöst. Nichts davon beeinträchtigt unbedingt die Produktion, aber es macht Order zu einem Teil mit zu vielen Verantwortlichkeiten.

Eine klarere Trennung könnte dazu führen, dass Order wesentliche Beziehungen, Attribute und Verhaltensweisen behält. CreateOrderAction oder OrderService würden den Anwendungsfall behandeln. OrderQuery würde komplexe Filter lösen. OrderResource würde die Ausgabe in API umwandeln. OrderPolicy würde über Berechtigungen entscheiden. Ein Job würde Benachrichtigungen oder umfangreiche Prozesse verwalten.

Verbesserung bedeutet nicht, „mehr Unterricht zu haben“. Die Verbesserung besteht darin, dass jede zukünftige Änderung einen offensichtlicheren Platz hat. Wenn Sie die Antwort von API ändern, berühren Sie das Modell nicht. Wenn sich die Berechtigung ändert, berühren Sie die Abfrage nicht. Wenn sich der Erstellungsprozess ändert, vermischen Sie diese Entscheidung nicht mit der Präsentation.

Bevor eine andere Methode innerhalb des Modells akzeptiert wird, lohnt es sich zu fragen: Repräsentiert sie das eigene Verhalten der Entität oder koordiniert sie einen Anwendungsfall? Hängt es von HTTP, Anfrage, Authentifizierung, Sitzung oder externem Kontext ab? Bereiten Sie eine Antwort für das Frontend oder API vor? Enthält es eine komplexe Abfrage, die schwer wiederzuverwenden ist?

Es hilft auch zu prüfen, ob Sie Geschäftsregeln mit Persistenz kombinieren, ob sie als Aktion, Dienst, Abfrageobjekt, Ressource oder Richtlinie klarer wären und ob sie getestet werden können, ohne zu viel Status um sie herum aufzubauen. Wenn die Antwort auf mehrere Fragen negativ ist, übernimmt das Modell wahrscheinlich Verantwortlichkeiten, die getrennt werden sollten.

Ein großes Modell bringt die Anwendung nicht immer zum Scheitern, deutet aber meist darauf hin, dass die Architektur ihre Grenzen verliert. Das wichtige Signal ist nicht die genaue Anzahl der Zeilen, sondern die Anzahl der verschiedenen Entscheidungen, die in derselben Klasse nebeneinander existieren.

Wenn Ihr Laravel funktioniert, aber jede Änderung anfängt, zu viele Teile zu berühren, kann Ihnen ein Backend-Audit Laravel dabei helfen, herauszufinden, welche Verantwortlichkeiten zuerst getrennt werden sollten und welche schnellen Erfolge die größte Wirkung haben.