Laravel für Enterprise-Systeme

Über kaum ein Werkzeug wird so viel Glaubensbekenntnis ausgetauscht wie über Web-Frameworks. Die einen halten Laravel für zu verspielt für ernste Systeme, die anderen für die Antwort auf jede Anforderung. Beide Lager stellen dieselbe untaugliche Frage — ob das Framework „gut genug" oder „besser" sei —, und beide bekommen darauf keine brauchbare Antwort, weil die Frage keine hat.

Dieses Dokument stellt eine andere Frage: Welche Eigenschaften hat ein System, und passen sie zu den Eigenschaften des Werkzeugs? Es behauptet nirgends, dass Laravel besser sei als eine Alternative. Es beschreibt, wo es trägt, wo es nicht trägt, und was es kostet, es über ein Jahrzehnt in einem geschäftskritischen Umfeld zu betreiben. Wer eine Empfehlung für das eigene Framework sucht, wird enttäuscht; wer eine Grundlage für eine begründete Entscheidung sucht, findet sie hier.

1. Was Enterprise wirklich bedeutet

„Enterprise" ist kein Größenmaß. Es beschreibt nicht die Zahl der Nutzer, den Umsatz des Unternehmens oder die Länge der Kundenliste. Es beschreibt eine Menge von Eigenschaften, die ein System schwer machen — unabhängig davon, wie viele Menschen es benutzen.

Ein Enterprise-System lebt lange, oft länger als die Teams, die es gebaut haben. Es hat viele Anspruchsgruppen mit widersprüchlichen Interessen. Es steht selten allein, sondern hängt in einem Geflecht aus anderen Systemen, die es weder kontrolliert noch abschalten kann. Es unterliegt Anforderungen an Nachvollziehbarkeit, Prüfbarkeit und Zugriffskontrolle, die nicht verhandelbar sind. Und es wird über Jahre von wechselnden Menschen weiterentwickelt, sodass die entscheidende Größe nicht ist, wie schnell ein Feature entsteht, sondern wie teuer eine Änderung in fünf Jahren sein wird.

Aus dieser Definition folgt der Maßstab für die Framework-Frage. Ein Framework ist für Enterprise geeignet, wenn es hilft, ein System über einen langen Zeitraum, mit wechselnden Teams und unter Integrationsdruck änderbar zu halten — nicht, wenn es die erste Version möglichst schnell liefert. Geschwindigkeit am Anfang ist billig zu haben; Änderbarkeit am Ende ist der eigentliche Preis.

Trade-off. Wer Enterprise über Eigenschaften statt über Größe definiert, verliert die einfache Ja/Nein-Antwort und muss pro System entscheiden. Das ist anstrengender, aber ehrlicher.

Kosten. Diese Sichtweise verlangt, die langfristigen Kosten einer Entscheidung abzuschätzen, bevor sie sichtbar werden — eine Disziplin, die im Projektdruck leicht dem nächsten Meilenstein geopfert wird.

Wann wir anders entscheiden. Trägt ein System keine dieser Eigenschaften — ein kurzlebiges Werkzeug, ein Prototyp, ein isolierter interner Helfer —, dann ist die Enterprise-Frage gegenstandslos, und man sollte nach reiner Liefergeschwindigkeit entscheiden.

2. Wo Laravel passt

Laravels Stärke liegt in Systemen, die von reicher Geschäftslogik, vielen Bildschirmen und Arbeitsabläufen geprägt sind — Anwendungen, in denen der Wert aus der Modellierung von Abläufen entsteht, nicht aus roher Rechenleistung. Für den weit überwiegenden Teil betrieblicher Software ist das genau die Beschreibung: Bestellungen, Verträge, Anträge, Freigaben, Abrechnungen, Verwaltung von Zuständen über die Zeit.

Der Grund ist das Ökosystem und die Reife der immer wiederkehrenden Bausteine. Authentifizierung, Autorisierung, Warteschlangen, geplante Aufgaben, Datenbankmigrationen, Validierung, Ereignisse, Testwerkzeuge — all das ist vorhanden, aufeinander abgestimmt und breit erprobt. Ein Team muss diese Fundamente nicht selbst bauen und kann seine Zeit auf das lenken, was das System einzigartig macht: die Fachlichkeit. Für Anwendungen mit vielen Standardbestandteilen und einem kleineren Kern echter Besonderheit ist dieser Zuschnitt sehr günstig.

Dazu kommt die Verfügbarkeit von Entwicklern. Ein Framework, das viele Menschen kennen, senkt die Kosten, ein Team über Jahre zu besetzen — eine Enterprise-Eigenschaft im Wortsinn, weil das System die Fluktuation seiner Erbauer überleben muss.

Trade-off. Dieselbe Fülle an fertigen Bausteinen, die den Anfang beschleunigt, verführt dazu, die Fachlichkeit in die Bausteine hineinzuziehen — was später teuer wird (siehe Kapitel 4).

Kosten. Die Reife des Ökosystems bindet an dessen Konventionen. Man erbt nicht nur die Bausteine, sondern auch ihre Annahmen; wer gegen sie arbeitet, verliert einen Teil des Vorteils.

Wann wir anders entscheiden. Besteht ein System fast nur aus einem kleinen, sehr speziellen Kern ohne die üblichen Standardbestandteile, schmilzt der Ökosystem-Vorteil, und die Wahl sollte allein nach den Eigenschaften dieses Kerns fallen.

3. Wo Laravel nicht passt

Ein ehrliches Entscheidungsdokument benennt die Grenzen deutlicher als die Stärken. Laravel — und das zugrunde liegende Ausführungsmodell — passt schlecht, wo die Anforderung nicht aus Fachlichkeit, sondern aus roher Maschineneigenschaft besteht.

Das betrifft zuerst rechenintensive Aufgaben im heißen Pfad: umfangreiche numerische Verarbeitung, Signal- oder Bildverarbeitung, alles, was von der reinen Ausführungsgeschwindigkeit einer Sprache lebt. Es betrifft harte Echtzeit und sehr niedrige, garantierte Latenz, wo jede Millisatz zählt und ein interpretiertes, pro Anfrage aufgebautes Modell im Weg steht. Es betrifft extrem hohe, dauerhafte Nebenläufigkeit auf einzelnen Verbindungen — etwa dauerhaft offene Verbindungen in sehr großer Zahl —, für die andere Ausführungsmodelle gebaut sind. Und es betrifft Umgebungen, in denen eine strikte, durchgängig vom Compiler erzwungene Typsicherheit eine gesetzte Anforderung ist; die dynamischen Wurzeln der Sprache erlauben zwar viel Disziplin, erzwingen sie aber nicht.

In diesen Fällen ist die passende Antwort nicht, Laravel „besser zu machen", sondern den betroffenen Teil in einem geeigneteren Werkzeug zu bauen und ihn über eine klare Schnittstelle anzubinden. Ein Enterprise-System ist ohnehin selten aus einem einzigen Werkzeug gebaut.

Trade-off. Einen Teil auszulagern kauft die passende Technologie mit einer zusätzlichen Systemgrenze, die betrieben und versioniert werden muss.

Kosten. Jede Sprach- und Laufzeitgrenze verdoppelt einen Teil des Betriebs: zwei Deployments, zwei Beobachtungsketten, zwei Kompetenzprofile im Team.

Wann wir anders entscheiden. Ist der rechenintensive oder latenzkritische Anteil klein und selten, kann es günstiger sein, ihn mit Zwischenspeicherung oder asynchroner Verarbeitung im Bestand zu entschärfen, statt eine zweite Technologie einzuführen. Erst wenn dieser Anteil den Charakter des Systems prägt, wiegt die zusätzliche Grenze ihren Preis auf.

4. Architekturprinzipien

Der wichtigste Satz zu Laravel im Enterprise-Kontext lautet: Das Framework ist die Schale, nicht der Kern. Laravel erlaubt — und lädt geradezu ein —, die Fachlichkeit direkt in seine Bausteine zu schreiben: Geschäftsregeln im Controller, Verhalten im Eloquent-Model, Abläufe in Framework-Ereignissen. Für eine kleine Anwendung ist das schnell und angemessen. Für ein langlebiges System ist es die Ursache der meisten späteren Schmerzen, weil es die Fachlichkeit an die Version des Frameworks fesselt.

Das leitende Prinzip ist deshalb, die Geschäftslogik framework-unabhängig zu halten — in einer Domänenschicht, die nichts von HTTP, nichts von Eloquent und nichts von Laravels Lebenszyklus weiß. Die Regeln des Geschäfts stehen in einfachen Klassen; das Framework ruft sie auf, statt sie zu enthalten. Eloquent wird dann als das behandelt, was es ist — ein Zugang zur Persistenz —, nicht als Ort der Fachlichkeit. Dieses Prinzip ist an anderer Stelle ausführlich behandelt: Business-Logik gehört nicht in Controller.

Strukturell heißt das für die meisten Enterprise-Systeme: ein modularer Monolith mit klaren inneren Grenzen, in dem die Abhängigkeiten nach innen zeigen — von der Framework-Schale zum fachlichen Kern, nie umgekehrt. So bleibt der Kern von den Moden des Frameworks unberührt, und ein Upgrade betrifft die Schale, nicht das Geschäft.

Schema: Das Framework umgibt die Fachlichkeit und ruft sie auf. Die Abhängigkeiten zeigen nach innen — der Kern kennt das Framework nicht.

Trade-off. Eine eigene Domänenschicht bedeutet, einen Teil von Laravels Bequemlichkeit bewusst nicht zu nutzen; die erste Version entsteht langsamer als mit Logik im Controller.

Kosten. Diese Disziplin verlangt erfahrenere Entwickler und mehr Struktur von Anfang an — Aufwand, der sich erst über die Lebensdauer auszahlt, im ersten Quartal aber wie Ballast wirkt.

Wann wir anders entscheiden. Für kurzlebige oder kleine Anwendungen ist die framework-nahe Bauweise die richtige: Dort ist die enge Bindung an Laravel kein Risiko, sondern Tempo, und eine Domänenschicht wäre überkonstruiert.

5. Langfristige Wartbarkeit

Wartbarkeit über Jahre entscheidet sich an zwei Größen: wie teuer Upgrades sind und wie viel „Magie" im Kern steckt. Laravel entwickelt sich in regelmäßigen Hauptversionen weiter. Das ist ein Vorteil — das Framework bleibt lebendig und gepflegt — und eine Verpflichtung: Wer Versionssprünge aufschiebt, sammelt eine Schuld an, die mit jeder ausgelassenen Version schwerer abzutragen ist.

Der wirksamste Hebel gegen diese Schuld ist die Trennung aus Kapitel 4. Steckt die Fachlichkeit in einem framework-unabhängigen Kern, betrifft ein Upgrade nur die Schale, und die Kosten bleiben beherrschbar. Ist die Fachlichkeit dagegen über Controller, Models und Framework-Ereignisse verstreut, wird jedes Upgrade zu einer Wanderung durch das ganze System. Die Upgrade-Kosten sind also weniger eine Eigenschaft des Frameworks als eine Eigenschaft der eigenen Architektur.

Die zweite Größe ist die „Magie" — Laravels Vorliebe für implizites Verhalten, das wenig Code verlangt, aber auch wenig zeigt. Sie beschleunigt das Schreiben und verlangsamt das Lesen. In einem System, das über Jahre öfter gelesen als geschrieben wird, kehrt sich die Rechnung um: Was am ersten Tag Tastenanschläge spart, kostet am tausendsten Tag Verständniszeit. Enterprise-Reife bei Laravel heißt, die Magie dort zurückzunehmen, wo Klarheit wichtiger ist als Kürze — im fachlichen Kern —, und sie dort zu nutzen, wo sie schadlos ist — in der Schale.

Trade-off. Explizit statt magisch zu bauen kostet mehr Zeilen und mehr anfängliche Mühe für den Gewinn, dass ein Fremder den Code Jahre später versteht.

Kosten. Eine disziplinierte Upgrade-Kadenz bindet dauerhaft Kapazität, die nichts Sichtbares liefert — bezahlte Vorsorge gegen einen Ausfall, der ohne sie später umso teurer eintritt.

Wann wir anders entscheiden. Wo ein System absehbar kurzlebig ist, ist die magische, framework-nahe Bauweise die wirtschaftlich richtige, und eine strenge Upgrade-Disziplin wäre Aufwand ohne Gegenwert.

6. Skalierungsrealität

Um Skalierung ranken sich die meisten Mythen. Die nüchterne Realität: Laravel-Anwendungen skalieren horizontal gut, weil sie sich zustandslos betreiben lassen — man stellt mehr gleichartige Anwendungsinstanzen hinter einen Lastverteiler, und die Anfragelast verteilt sich. Der Engpass ist fast nie die Anwendungsschicht. Er ist die Datenbank, den sich alle Instanzen teilen.

Das verschiebt die Skalierungsarbeit weg vom Framework hin zu Datenmodell, Indizierung, Abfragen und dem bewussten Auslagern von Arbeit. Zwei Werkzeuge tragen den Großteil: Warteschlangen, um Arbeit aus dem Anfragepfad zu nehmen (Queue oder synchrone Verarbeitung behandelt die verwandte Abwägung), und Zwischenspeicherung, um wiederholte Leselast von der Quelle fernzuhalten — mit allen Vorbehalten, die das mit sich bringt. Beides sind Architekturentscheidungen, keine Framework-Schalter.

Eine eigene Betrachtung verdient das Ausführungsmodell. Klassisch verarbeitet die Anwendung jede Anfrage in einem frisch aufgebauten Prozess: einfach, robust, gut isoliert — aber mit dem wiederkehrenden Aufwand des Aufbaus pro Anfrage. Ein alternatives Modell hält die Anwendung als langlaufenden Prozess im Speicher und spart diesen Aufbau, um den Preis, dass Zustand zwischen Anfragen überlebt und sorgfältig sauber gehalten werden muss. Das ist ein echter Trade-off, keine reine Verbesserung.

Schema: Die zustandslose Anwendungsschicht skaliert durch Vervielfachung. Der geteilte Speicher dahinter tut es nicht — dort liegt die eigentliche Skalierungsarbeit.

Trade-off. Horizontale Skalierung ist billig an der Anwendung und teuer an der Datenbank; die Wahl, Arbeit auszulagern, kauft Entlastung mit Komplexität.

Kosten. Jede Skalierungsmaßnahme — Queue, Cache, langlaufender Prozess — fügt einen betrieblichen Teil hinzu, der überwacht und im Fehlerfall verstanden werden muss.

Wann wir anders entscheiden. Solange eine einzelne Instanz und eine gut indizierte Datenbank die Last tragen, führen wir keine dieser Maßnahmen ein — sie lösen ein Problem, das man erst gemessen haben muss, bevor man es hat.

7. Betrieb

Ein Enterprise-System wird länger betrieben als entwickelt, und der Betrieb entscheidet über Ruf und Kosten. Laravels betriebliche Oberfläche ist größer als die einer reinen Anwendung: Neben den Anwendungsinstanzen laufen Warteschlangen-Arbeiter, geplante Aufgaben und oft ein Cache- und ein Queue-Dienst. Jeder dieser Teile ist ein eigener Betriebsgegenstand mit eigenen Fehlermodi.

Zwei Bereiche verdienen besondere Sorgfalt. Der erste ist das Ausrollen neuer Versionen ohne Ausfall, besonders im Zusammenspiel mit Datenbankänderungen — eine eigene Disziplin, die in Zero-Downtime-Datenbankmigrationen behandelt wird und die man nicht dem Zufall überlassen darf. Der zweite sind die Warteschlangen-Arbeiter: Sie sind kein „Feuern und Vergessen", sondern brauchen einen Plan für fehlgeschlagene Aufträge, für Wiederholungen und für den Fall, dass ein Arbeiter mitten in der Verarbeitung stirbt — dieselbe Wiederholbarkeitsdisziplin, die verteilte Systeme insgesamt verlangen.

Über allem steht die Beobachtbarkeit. Ein System, dessen Warteschlangen, geplante Aufgaben und Zwischenspeicher man nicht messen kann, ist im Fehlerfall eine Blackbox. Beobachtbarkeit ist deshalb keine spätere Zutat, sondern Teil der Architektur — so behandelt in Observability als Architekturprinzip.

Trade-off. Die reiche betriebliche Ausstattung — Queues, Scheduler, Cache — kauft Fähigkeiten mit einer größeren Fläche, die ausfallen kann.

Kosten. Jeder betriebliche Teil verlangt Überwachung, Alarmierung und eingeübte Reaktionen; der Betrieb eines Enterprise-Laravel ist mehr als das Ausrollen einer Anwendung.

Wann wir anders entscheiden. Wo eine Anwendung ohne Hintergrundarbeit auskommt, verzichten wir bewusst auf Queue und Scheduler, statt die Oberfläche „für später" aufzubauen — ungenutzte Betriebsteile sind Risiko ohne Gegenwert.

8. Team-Organisation

Die niedrige Einstiegshürde von Laravel ist zugleich sein größtes organisatorisches Risiko. Sie macht Teams schnell produktiv und erleichtert das Besetzen von Stellen — beides echte Enterprise-Vorteile. Dieselbe Zugänglichkeit erlaubt aber auch, jede Abkürzung zu nehmen: Geschäftslogik in den Controller, einen weiteren Zugriff im Model, noch ein Paket für ein kleines Problem. Was das Framework erlaubt, wird ein Team unter Druck auch tun, wenn nichts es aufhält.

Der Ausgleich liegt nicht im Framework, sondern in der Organisation: verbindliche Konventionen, die über die des Frameworks hinausgehen und die Fachlichkeit vom Framework trennen; Grenzen im Code, die zu den Grenzen zwischen Teams passen, sodass ein Team einen Bereich besitzt, statt dass alle überall schreiben; und ein Review, das nicht auf Stil achtet, sondern darauf, dass die Fachlichkeit dort landet, wo sie hingehört. Die Konventionen des Frameworks sind ein Geschenk an das Onboarding — aber sie ersetzen nicht die architektonischen Konventionen, die ein langlebiges System zusammenhalten.

Trade-off. Zusätzliche, hauseigene Konventionen kosten Freiheit und Anfangstempo für den Gewinn, dass viele Hände über Jahre am selben System arbeiten können, ohne es zu zerfasern.

Kosten. Konventionen müssen geschrieben, gelehrt und im Review durchgesetzt werden — eine dauerhafte Investition in Disziplin, die kein Feature liefert.

Wann wir anders entscheiden. In einem kleinen Team an einer kleinen Anwendung wären schwere Konventionen Bürokratie; dort genügen die Framework-Konventionen, und zusätzliche Struktur würde mehr bremsen als schützen.

9. Typische Fehler

Die wiederkehrenden Muster, an denen Enterprise-Laravel scheitert — fast alle sind Varianten desselben Fehlers, das Framework zum Kern statt zur Schale zu machen:

• Geschäftslogik in Controllern und Eloquent-Models, sodass die Fachlichkeit an die Framework-Version gefesselt ist und jedes Upgrade das ganze System berührt.
• Auf implizite „Magie" im fachlichen Kern setzen und damit Schreibtempo gegen jahrelange Lesekosten eintauschen.
• Upgrades aufschieben, bis der Sprung über mehrere Versionen zu groß und zu riskant für einen ruhigen Moment geworden ist.
• Skalierung im Framework suchen, obwohl der Engpass die geteilte Datenbank ist — Indizes und Abfragen bleiben ungeprüft.
• Warteschlangen als „Feuern und Vergessen" behandeln, ohne Plan für fehlgeschlagene, doppelte oder mittendrin abgebrochene Aufträge.
• Für jedes kleine Problem ein weiteres Paket ziehen und so eine Abhängigkeitslast aufbauen, die bei jedem Upgrade mitwandern muss.
• Die niedrige Einstiegshürde mit architektonischer Reife verwechseln und ohne Grenzen bauen, bis alle überall schreiben.
• Einen rechenintensiven oder latenzkritischen Teil im Framework erzwingen, statt ihn in einem geeigneteren Werkzeug hinter einer Grenze zu bauen.
• Beobachtbarkeit für Queues, Scheduler und Cache erst nachrüsten, wenn im Betrieb schon etwas Unerklärliches passiert ist.

10. Entscheidungs-Checkliste

Vor der Wahl von Laravel für ein Enterprise-System der Reihe nach zu klären:

• Charakter des Systems? Entsteht der Wert aus Fachlichkeit, Abläufen und vielen Bildschirmen — oder aus roher Rechenleistung und garantierter niedriger Latenz?
• Heißer Pfad rechenintensiv? Gibt es einen Teil, der von reiner Ausführungsgeschwindigkeit lebt — und gehört der dann hinter eine Grenze in ein anderes Werkzeug?
• Domänenschicht geplant? Ist entschieden, die Fachlichkeit framework-unabhängig zu halten, statt sie in Controller und Models zu schreiben?
• Struktur? Ist ein modularer Monolith mit nach innen zeigenden Abhängigkeiten vorgesehen, oder wächst das System ungeordnet?
• Upgrade-Disziplin? Ist die Kapazität für eine regelmäßige Versionspflege eingeplant, bevor die Schuld sich anhäuft?
• Skalierung an der richtigen Stelle? Ist klar, dass die Datenbank der Engpass ist und die Skalierungsarbeit dort und in bewusster Auslagerung liegt?
• Betrieb bedacht? Sind Zero-Downtime-Ausrollung, Warteschlangen-Fehlerfälle und Beobachtbarkeit von Anfang an vorgesehen?
• Team und Konventionen? Gibt es hauseigene Konventionen und Code-Grenzen, die die Fachlichkeit schützen, wo das Framework Abkürzungen erlaubt?
• Ehrliche Alternative geprüft? Wurde die Wahl gegen eine konkrete Alternative anhand der Systemeigenschaften begründet — nicht anhand von Vorliebe?

Wer diese Fragen nicht beantworten kann, wählt kein Enterprise-Framework, sondern ein Startgefühl — und zahlt die Differenz über die Lebensdauer.

FAQ

Ist Laravel „Enterprise-ready"? Die Frage hat keine sinnvolle Antwort, weil „Enterprise" keine Eigenschaft eines Frameworks ist, sondern eines Systems. Laravel trägt langlebige, geschäftskritische Systeme gut, sofern man die Fachlichkeit vom Framework trennt und eine Upgrade-Disziplin hält. Ohne diese Architektur trägt kein Framework über Jahre — auch ein „seriöseres" nicht.

Ist Laravel schneller oder besser als eine strengere Alternative? Nicht pauschal, und die Frage führt in die Irre. Es ist für einen bestimmten Systemtyp — fachlichkeitsreiche Anwendungen mit vielen Standardbestandteilen — sehr passend und für andere — rechen- oder latenzgetriebene Kerne — weniger. Die Wahl fällt an den Eigenschaften des Systems, nicht an einem Ranking der Frameworks.

Skaliert Laravel für große Last? Die zustandslose Anwendungsschicht skaliert horizontal gut; der Engpass ist fast immer die geteilte Datenbank. „Skaliert Laravel" ist deshalb selten die richtige Frage — die richtige lautet, ob Datenmodell, Indizierung und die Auslagerung von Arbeit die erwartete Last tragen.

Sollten wir alles in Laravel bauen oder Teile auslagern? Prägt ein rechenintensiver oder latenzkritischer Anteil den Charakter des Systems, baut man ihn in einem geeigneteren Werkzeug hinter einer klaren Schnittstelle. Ist der Anteil klein und selten, ist es meist günstiger, ihn mit Zwischenspeicherung oder asynchroner Verarbeitung im Bestand zu entschärfen, als eine zweite Technologie zu betreiben.

Wie halten wir die Upgrade-Kosten niedrig? Indem die Fachlichkeit in einem framework-unabhängigen Kern liegt. Dann betrifft ein Upgrade nur die Schale. Die Upgrade-Kosten sind weniger eine Eigenschaft von Laravel als eine Eigenschaft der eigenen Architektur — und der Regelmäßigkeit, mit der man Versionen nachzieht.

Ist die niedrige Einstiegshürde nicht ein Vorteil im Enterprise? Sie ist beides. Sie senkt Onboarding- und Besetzungskosten und erlaubt zugleich jede Abkürzung. Der Vorteil bleibt nur mit hauseigenen Konventionen und Code-Grenzen, die verhindern, dass aus schneller Produktivität ein zerfasertes System wird.

Weiterführend

• Laravel oder Symfony — der ehrliche Architekturvergleich der beiden PHP-Frameworks, ohne Sieger.
• Business-Logik gehört nicht in Controller — das zentrale Prinzip, die Fachlichkeit vom Framework zu trennen.
• Modularer Monolith vs. Microservices und die zugehörige Entscheidung — die passende Grundstruktur für die meisten Enterprise-Systeme.
• Software, die in zehn Jahren noch läuft — warum Änderbarkeit über die Lebensdauer der eigentliche Maßstab ist.

Grundlage ist die Batunet Engineering Method: an den Eigenschaften des Systems entscheiden, die Fachlichkeit vom Werkzeug trennen, für die Lebensdauer bauen.

Ein Framework ist ein Werkzeug, kein Bekenntnis. Die Frage ist nie, ob es gut ist, sondern ob es zu dem passt, was man baut — und was es kostet, es zehn Jahre zu tragen.