Laravel-Entwicklung
Wir bauen mit Laravel, wo es die richtige Wahl ist — und sagen, wo nicht. Von der Domänenmodellierung über Queues und Octane bis zum Betrieb unter Last.
Laravel-Entwicklung in einer Minute.
Für Entscheider: unsere Position auf einen Blick — wann es passt, wie wir es angehen, worauf wir optimieren.
- Laravel passt, wenn
- eine klare Geschäftsdomäne mit Web- oder API-Fokus entsteht und Time-to-Market zählt.
- Laravel wird schwierig, wenn
- harte Echtzeit, CPU-gebundene Last oder strengste Architekturtrennung ab Tag eins gefordert sind.
- Bevorzugte Architektur
- modularer Monolith, Geschäftslogik unabhängig von Eloquent, API-first bei mehreren Clients.
- Typische Projektgröße
- mittlere bis große Geschäftsanwendungen — ein Team, mehrere Module, ein Deployment.
- Typische Risiken
- Fat Models, fehlende Idempotenz bei asynchroner Verarbeitung, Framework-Magie statt Domänenmodell.
- Worauf wir optimieren
- Änderbarkeit über Jahre, nachvollziehbaren Betrieb und eine vom Framework unabhängige Domäne.
- Was wir bewusst vermeiden
- vorzeitige Microservices, No-Code-Abkürzungen und Geschäftslogik in Controllern und Models.
- Erwartete Lebensdauer
- Systeme, die auf einen produktiven Betrieb über fünf bis zehn Jahre ausgelegt sind.
Risiken, die wir früh erkennen.
Was in Systemen dieser Art typischerweise schiefgeht — und wie wir es vermeiden, bevor es in Produktion sichtbar wird.
- 01
Fat Models
- Warum
- Eloquent macht es leicht, Geschäftsregeln direkt ins Model zu legen. Das wächst mit dem System, bis das Model alles weiß und niemand mehr folgt.
- Frühwarnzeichen
- Models mit vielen Verantwortlichkeiten und Tests, die die halbe Anwendung hochfahren müssen.
- Wie wir es verhindern
- Geschäftslogik in Services, Aktionen und Value Objects; das Model bleibt für Persistenz zuständig, nicht für Regeln.
- Trade-off
- Kosten: mehr Klassen und etwas mehr Aufbau. Anders, wenn: eine kleine, kurzlebige Anwendung — dann darf das Model mehr tragen.
- 02
Logik im Controller
- Warum
- Der schnellste Weg ist, alles im Controller zu erledigen. Das funktioniert — bis dieselbe Logik an zweiter Stelle gebraucht wird.
- Frühwarnzeichen
- Controller mit Geschäftsregeln, Duplikate zwischen Controllern, schwer testbare Endpunkte.
- Wie wir es verhindern
- Der Controller nimmt entgegen, validiert und delegiert an die Domäne. Er entscheidet nicht.
- Trade-off
- Kosten: eine zusätzliche Schicht. Anders, wenn: ein trivialer Endpunkt ohne Wiederverwendung — dann bleibt es schlank.
- 03
Queue ohne Idempotenz
- Warum
- Queues stellen mindestens einmal zu. Ohne Idempotenz erzeugt eine doppelte Zustellung doppelte Effekte — doppelte Benachrichtigungen, doppelte Buchungen.
- Frühwarnzeichen
- Jobs ohne eindeutigen Schlüssel, Nebenwirkungen ohne Prüfung, gelegentliche Duplikate ohne klare Ursache.
- Wie wir es verhindern
- Jeder Job ist idempotent: ein Schlüssel wird in derselben Transaktion wie der Effekt geprüft und persistiert.
- Trade-off
- Kosten: ein Schlüsselspeicher mit Retention. Anders, wenn: der Effekt von Natur aus idempotent ist — dann genügt das.
- 04
Cache-Invalidierung
- Warum
- Caching ist leicht hinzugefügt und schwer korrekt zu halten. Ohne klare Regeln liefert der Cache irgendwann veraltete Daten.
- Frühwarnzeichen
- Caches ohne definierte Invalidierung, „manchmal alte Daten“, Debugging über das Leeren des Caches.
- Wie wir es verhindern
- Was gecacht wird und wann es ungültig wird, ist Teil des Entwurfs — kein Nachgedanke.
- Trade-off
- Kosten: Konsistenz vorab durchdenken. Anders, wenn: Konsistenz wichtiger ist als Latenz — dann nicht cachen, sondern die Abfrage optimieren.
- 05
Fehlende Observability
- Warum
- Solange alles läuft, fällt fehlende Sichtbarkeit nicht auf. Beim ersten Incident fehlen dann die Signale, um zu verstehen, was passiert ist.
- Frühwarnzeichen
- Keine strukturierten Logs, keine Traces, Fragen zum Betrieb, die niemand beantworten kann.
- Wie wir es verhindern
- Logs, Metriken und Traces gehören zum ersten Tag; das System kann sagen, warum ein Request langsam war.
- Trade-off
- Kosten: Instrumentierung und kuratierte Signale. Anders, wenn: ein Wegwerf-Prototyp — dann minimal.
- 06
Datenbank-Engpässe
- Warum
- Der Engpass ist fast immer die Datenbank, nicht das Framework. N+1-Abfragen und fehlende Indizes fallen erst unter Last auf.
- Frühwarnzeichen
- Langsame Endpunkte unter Last, viele kleine Abfragen pro Request, Query-Zeiten, die mit den Daten wachsen.
- Wie wir es verhindern
- Abfragen bewusst laden (Eager Loading), gezielte Indizes, Messung im Betrieb; die Datenbank ist der erste Ort, an dem wir suchen.
- Trade-off
- Kosten: Aufmerksamkeit für Abfragen statt „einfach Eloquent“. Anders, wenn: kleines Datenvolumen — dann ist der Aufwand unnötig.
- 07
Vorzeitige Microservices
- Warum
- Microservices gelten als Standard für ernsthafte Systeme. Zu früh eingeführt, zahlt man Netzwerkgrenzen und Betriebsaufwand ohne den Nutzen.
- Frühwarnzeichen
- Verteilte Dienste ohne unabhängige Skalierung, ein Team, das mehrere Dienste synchron ausrollt — ein verteilter Monolith.
- Wie wir es verhindern
- Start als modularer Monolith mit klaren Grenzen; ein Dienst wird nur herausgelöst, wenn eine konkrete Anforderung es verlangt.
- Trade-off
- Kosten: kein unabhängiges Skalieren einzelner Teile zu Beginn. Anders, wenn: Teile nachweislich radikal unterschiedliche Anforderungen haben.
- 08
Framework-Kopplung
- Warum
- Hängt die Domäne direkt an Eloquent und Framework-Magie, wird jede Änderung — und jedes Upgrade — teurer.
- Frühwarnzeichen
- Geschäftsregeln in Eloquent-Models, Tests, die die Datenbank brauchen, Zurückhaltung bei Framework-Upgrades.
- Wie wir es verhindern
- Die Domäne bleibt unabhängig vom Framework; Laravel ist Infrastruktur, nicht der Ort der Geschäftslogik.
- Trade-off
- Kosten: etwas mehr Struktur von Beginn an. Anders, wenn: eine kurzlebige Anwendung ohne langfristige Wartung.
Die Fragen, die wir vor dem Code stellen.
Keine Ratschläge, sondern Entscheidungsfragen. Ihre Antworten prägen die Architektur — nicht die Werkzeuge.
- 01
Teilen sich mehrere Clients dieselbe Geschäftslogik?
- Warum das zählt
- Sobald mehrere Frontends oder Partner dasselbe System nutzen, wird die Schnittstelle zum Vertrag, den man nicht mehr frei ändern kann.
- Typische Konsequenz
- Ist die Antwort ja, entwerfen wir API-first — versioniert und dokumentiert, bevor die Weboberfläche entsteht.
- 02
Brauchen wir asynchrone Verarbeitung?
- Warum das zählt
- Langsame oder unzuverlässige Nebenwirkungen im kritischen Antwortpfad koppeln Latenz und Fehler an das langsamste beteiligte System.
- Typische Konsequenz
- Wenn ja, wandern sie idempotent in eine Queue; wenn nein, bleibt der Pfad synchron und einfach.
- 03
Ist strenge Architekturtrennung von Beginn an gefordert?
- Warum das zählt
- Manche Kontexte verlangen harte Grenzen ab Tag eins — regulatorisch oder wegen sehr großer Domänen.
- Typische Konsequenz
- Ist das der Fall, prüfen wir, ob Symfony die tragfähigere Basis ist; sonst genügt ein sauber geschnittener modularer Monolith.
- 04
Wie lange muss dieses System leben?
- Warum das zählt
- Die erwartete Lebensdauer bestimmt, wie viel Struktur und Dokumentation sich früh lohnen.
- Typische Konsequenz
- Für einen Betrieb über Jahre trennen wir die Domäne konsequent vom Framework; für ein kurzlebiges Experiment nicht.
- 05
Wie oft ändern sich die Geschäftsregeln?
- Warum das zählt
- Häufig geänderte Regeln müssen an einer Stelle liegen, nicht über Controller und Models verstreut.
- Typische Konsequenz
- Bei hoher Änderungsrate kapseln wir Regeln in der Domäne; bei stabilen Regeln darf es schlanker sein.
- 06
Ist Sichtbarkeit im Betrieb erforderlich?
- Warum das zählt
- Ein System, das im Betrieb Fragen beantworten muss, braucht Signale, die nur beim Entwurf entstehen können.
- Typische Konsequenz
- Wenn ja, gehören Logs, Metriken und Traces von Beginn an dazu; nachträglich sind sie schwer einzubauen.
- 07
Darf Konsistenz eventual werden?
- Warum das zählt
- Asynchronität und Caching bringen eventual consistency mit — die Oberfläche und die Nutzer müssen das vertragen.
- Typische Konsequenz
- Wo ja, kommunizieren wir Zustände ehrlich (etwa „in Arbeit“); wo nein, bleibt der Pfad synchron und konsistent.
- 08
Welcher Pfad trägt das größte Risiko?
- Warum das zählt
- Das größte Risiko sollte am Anfang stehen, nicht am Ende der Entwicklung sichtbar werden.
- Typische Konsequenz
- Wir beweisen den schwierigsten Pfad zuerst End-to-End; alles Weitere baut darauf auf.
Was das ist — und was dazugehört.
Laravel ist ein ausgereiftes PHP-Framework für Webanwendungen und APIs. Wir setzen es für Geschäftsanwendungen ein, deren Anforderungen über einfaches CRUD hinausgehen: klar geschnittene Domänen, verlässliche Hintergrundverarbeitung und ein Betrieb, der auch in fünf Jahren noch nachvollziehbar ist. Laravel bleibt dabei die Infrastruktur — die Geschäftslogik bleibt davon unabhängig.
Leistungsumfang
- Domänenmodell und Architektur
- APIs und Integrationen (REST, versioniert)
- Asynchrone Verarbeitung mit Queues und Horizon
- Caching, Redis und Performance
- Tests, CI/CD und Betrieb
Entscheidungen, bevor Code entsteht.
Nicht was die Technik kann, sondern warum wir sie so einsetzen.
- 01
Modularer Monolith vor Microservices
Die meisten Laravel-Systeme starten am besten als modularer Monolith: klare Modulgrenzen innerhalb einer Codebasis. Das hält die Komplexität niedrig, solange verteilte Systeme nicht wirklich gebraucht werden — und lässt sich später gezielt auftrennen, wenn eine Grenze es verlangt.
- 02
Geschäftslogik raus aus dem Framework
Regeln gehören in Services, Aktionen und Value Objects — nicht in Controller oder Models. So bleibt die Domäne testbar und unabhängig von Eloquent. Der Controller nimmt entgegen und delegiert; er entscheidet nicht.
- 03
Eloquent bewusst, nicht dogmatisch
Eloquent ist für den Großteil der Zugriffe produktiv und lesbar. Für komplexe oder performancekritische Abfragen greifen wir gezielt zum Query Builder. Das Repository-Pattern setzen wir nur dort ein, wo es echte Entkopplung bringt — nicht als Selbstzweck.
- 04
API-first, wo mehrere Clients zugreifen
Sobald Partner, mobile Apps oder mehrere Frontends ein System nutzen, entwerfen wir die API zuerst: versioniert, dokumentiert, als stabiler Vertrag. Die Weboberfläche ist dann einer von mehreren Konsumenten, nicht das System selbst.
So bauen wir. Die Batunet Engineering Method.
Sieben Phasen — von der ersten Frage bis zum Betrieb nach Jahren. Kein Projektprozess, sondern die Art, wie wir denken.
- 01
FrameRahmen
Das eigentliche Problem, seine Grenzen und ein messbarer Erfolg werden definiert, bevor eine Lösung erwogen wird.
- 02
ModelModellieren
Die Domäne wird modelliert und in Kontexte geschnitten — mit einer präzisen, gemeinsamen Sprache.
- 03
DecideEntscheiden
Die tragenden Entscheidungen fallen zuerst, bewusst und dokumentiert, solange Ändern noch günstig ist.
- 04
ProveBeweisen
Ein lauffähiges Skelett beweist die Architektur auf dem riskantesten Pfad — vor der Breite.
- 05
BuildBauen
Auf dem bewiesenen Skelett entsteht das System in prüfbaren, umkehrbaren Schritten — Fortschritt wöchentlich sichtbar.
- 06
HardenHärten
Fehlerfälle, Last und Sicherheit werden geprüft, nicht angenommen. Aus „läuft“ wird „hält“.
- 07
OperateBetreiben
Wir betreiben, überwachen und entwickeln weiter — und halten das System verständlich und änderbar.
Vom Entwurf bis zum Betrieb.
Das System muss nicht nur laufen, sondern im Betrieb bestehen. Jede Empfehlung mit ihren Kosten — und dem Fall, in dem wir anders entscheiden.
Queues & Horizon
Alles, was warten kann, läuft asynchron über Queues. Horizon macht Worker, Durchsatz, Laufzeiten und fehlgeschlagene Jobs mit Retry-Strategie sichtbar.
Trade-off · Kosten: eventual consistency und die Pflicht zur Idempotenz. Anders, wenn: die Operation für die Antwort kritisch ist — dann bleibt sie synchron.
Octane — Performance-Engineering
Für latenzkritische Dienste hält Octane die Anwendung zwischen Requests im Speicher und senkt so die Latenz spürbar. Zuerst messen wir aber, wo die Zeit wirklich verloren geht — meist in der Datenbank.
Trade-off · Kosten: zustandsfreier Code, sorgfältiges Ressourcen-Handling, Risiko von Memory-Leaks. Anders, wenn: die Latenz unkritisch ist — dann genügt klassisches PHP-FPM und ist einfacher zu betreiben.
Caching & Redis
Redis dient als Cache, Queue-Backend und für verteilte Locks. Was gecacht wird und wie es invalidiert, ist eine bewusste Entwurfsentscheidung: Was darf veralten, was muss konsistent sein?
Trade-off · Kosten: Cache-Invalidierung ist schwer; falsches Caching liefert veraltete Daten. Anders, wenn: Konsistenz wichtiger ist als Latenz — dann cachen wir nicht, sondern optimieren die Abfrage.
Ereignisgetriebene Entkopplung
Domain Events trennen Nebenwirkungen von der Hauptlogik. Über die Queue verarbeitet, halten sie Transaktionen schlank und das System erweiterbar, ohne bestehende Pfade zu berühren.
Trade-off · Kosten: mehr indirekte Flüsse, schwerer nachzuvollziehen. Anders, wenn: der Ablauf einfach und synchron klar ist — dann kein Event.
Observability
Strukturierte Logs, Metriken und Traces gehören zum ersten Tag, nicht zum ersten Incident. Ein System im Betrieb muss beantworten können, warum ein bestimmter Request langsam war.
Trade-off · Kosten: Instrumentierung, Speicher und die Disziplin, Signale zu kuratieren statt Lärm zu erzeugen. Anders, wenn: ein kurzlebiger Prototyp — dann minimale Instrumentierung.
Teststrategie
Feature-Tests auf den kritischen Pfaden, Unit-Tests für die Domänenlogik. Tests dort, wo Fehler teuer werden — und als Netz für sichere Änderungen über Jahre.
Trade-off · Kosten: Testpflege und langsamere erste Auslieferung. Anders, wenn: ein Wegwerf-Spike ohne Produktivcode — dann kein Test.
Deployment ohne Downtime
Reproduzierbare Deployments (Docker, Forge/Envoyer) mit Health-Checks. Schemaänderungen laufen rückwärtskompatibel nach dem expand/contract-Muster: erst additiv erweitern, dann den Code umstellen, zuletzt aufräumen.
Trade-off · Kosten: zweiphasige Migrationen und mehr Deployment-Disziplin. Anders, wenn: ein kurzes Wartungsfenster akzeptabel ist — dann genügt ein einfacherer Migrationspfad.
Sicherheit — Standards statt Eigenbau
Authentifizierung über etablierte Pakete (etwa Sanctum oder OIDC), Least-Privilege, Secrets außerhalb des Codes, validierte Eingaben und escapte Ausgaben. Sicherheit ist eine Entwurfsentscheidung, kein Audit am Ende.
Trade-off · Kosten: weniger Freiheit, mehr Konvention. Anders, wenn: eine sehr spezielle Anforderung besteht — dann bewusst und geprüft abweichen, nie improvisiert.
Upgrade-Strategie
Wir folgen Laravels jährlichem Release-Zyklus mit disziplinierten, getesteten Upgrades und halten die Abhängigkeiten aktuell und bewusst gering.
Trade-off · Kosten: regelmäßiger Upgrade-Aufwand durch das kürzere Supportfenster. Anders, wenn: maximale Upgrade-Ruhe über viele Jahre im Vordergrund steht — dann ist Symfony mit LTS die tragfähigere Basis.
Langfristiger Betrieb & Wartbarkeit
Die Domäne bleibt unabhängig von Eloquent, tragende Entscheidungen werden als ADRs festgehalten, der Betrieb ist überwacht und die Verantwortung geklärt. So bleibt das System über Jahre sicher änderbar.
Trade-off · Kosten: mehr Struktur und Dokumentationsdisziplin von Beginn an. Anders, wenn: ein kurzlebiges Experiment — dann bewusst Tempo vor Struktur.
Risiko — der schwierige Pfad zuerst
Der riskanteste Pfad läuft zuerst End-to-End als lauffähiges Skelett. Fehlerfälle werden geprüft, nicht angenommen; jede Änderung bleibt umkehrbar.
Trade-off · Kosten: langsamer sichtbarer Fortschritt am Anfang. Anders, wenn: das Risiko nachweislich gering ist — dann direkt in die Breite.
Schematische Architektur.
Generische Auszüge — ohne Kundenbezug, aber so, wie wir tatsächlich entwerfen: ein modularer Monolith mit ereignisgetriebenem, idempotentem Pfad.
Worauf Sie sich verlassen können.
- 01
Ein System, dessen Geschäftslogik unabhängig vom Framework testbar bleibt
- 02
Nachvollziehbarer Betrieb: sichtbare Queues, Metriken und Logs
- 03
Eine Codebasis, die ein Team über Jahre weiterentwickeln kann
Wann es passt — und wann nicht.
Die ehrliche Antwort gehört zur Beratung. Wir empfehlen den Weg, der zum Problem passt.
Passt
- Geschäftsanwendungen mit klarer Domäne und Weboberfläche
- SaaS-Produkte, APIs und Portale mit Anspruch an Time-to-Market
- Systeme, die ein Team über Jahre warten und weiterentwickeln soll
- Vorhaben, die von einem großen, ausgereiften Ökosystem profitieren
Passt nicht
- Harte Echtzeit- oder sehr niedrige Latenzanforderungen auf Systemebene
- CPU-gebundene, rechenintensive Verarbeitung — dort passt ein anderer Stack
- Sehr kleine, statische Seiten ohne echte Anwendungslogik
- Fälle, in denen strengste Architekturtrennung ab Tag eins Pflicht ist — dort ist Symfony oft die tragfähigere Basis
Eingesetzte Technologien
Fragen zu Laravel-Entwicklung
Wann ist Laravel die richtige Wahl?
Wenn eine klar abgrenzbare Geschäftsdomäne mit Weboberfläche oder API entsteht, Time-to-Market zählt und ein Team das System über Jahre pflegen soll. Das ausgereifte Ökosystem nimmt wiederkehrende Arbeit ab, ohne die Kontrolle über die Architektur aufzugeben.
Wann ist Laravel nicht die richtige Wahl?
Bei harten Echtzeitanforderungen, CPU-gebundener Rechenlast oder wenn strengste Architekturtrennung ab dem ersten Tag Pflicht ist. In solchen Fällen empfehlen wir einen anderen Stack — oder Symfony, wenn die Trennung im Vordergrund steht.
Wie skaliert Laravel?
Horizontal: zustandsfreie App-Server hinter einem Load Balancer, Sessions und Cache in Redis, asynchrone Arbeit in Queues, Lesezugriffe über Read-Replicas. Der Engpass ist fast immer die Datenbank, nicht das Framework — dort setzen wir zuerst an. Octane senkt zusätzlich die Latenz, wo sie zählt.
Wie strukturiert ihr große Laravel-Projekte?
Als modularer Monolith mit Modulen entlang der Domäne, nicht entlang technischer Schichten. Die Geschäftslogik liegt in Services und Value Objects, unabhängig von Eloquent. Klare Modulgrenzen halten die Komplexität beherrschbar und ermöglichen eine spätere Auftrennung, falls nötig.
Wie bleibt eine Laravel-Anwendung über Jahre wartbar?
Durch eine vom Framework unabhängige Domäne, Tests entlang der Risiken, dokumentierte Entscheidungen (ADRs), disziplinierte Versions-Updates und bewusst gewählte, ausgereifte Abhängigkeiten. Wartbarkeit ist eine Folge von Entscheidungen, die früh getroffen werden.
Wie deployt ihr ohne Downtime?
Reproduzierbare Deployments mit Health-Checks und rückwärtskompatiblen Migrationen nach dem expand/contract-Muster: erst additive Schemaänderung, dann Code, dann Aufräumen. Der Preis ist eine zweiphasige Migration; wo ein kurzes Wartungsfenster akzeptabel ist, geht es einfacher.
Wie haltet ihr die Anwendung sicher?
Etablierte Auth-Pakete statt Eigenbau, Least-Privilege, Secrets außerhalb des Codes, validierte Eingaben und escapte Ausgaben. Sicherheit ist eine Entwurfsentscheidung von Beginn an, kein Audit am Ende — der Trade-off ist etwas weniger Freiheit zugunsten bewährter Konventionen.
Wie handhabt ihr Laravel-Upgrades?
Wir folgen dem jährlichen Release-Zyklus mit getesteten Upgrades und wenigen, aktuellen Abhängigkeiten. Der Preis ist regelmäßiger Aufwand durch das kürzere Supportfenster; wer maximale Upgrade-Ruhe über viele Jahre braucht, ist mit Symfony und seiner LTS-Politik oft besser bedient.
Gehört uns der Quellcode?
Ja. Quellcode, Infrastruktur und Dokumentation werden vollständig übergeben. Sie bleiben unabhängig — auch von uns.
Setzen Sie Ihren Engineering-Weg fort.
Verwandte Konzepte, Entscheidungen, Playbooks und Standpunkte — als zusammenhängender Pfad, nicht als Linkliste.
Technologien
Leistungen
Verwandte Konzepte
Sprechen wir über Ihr Vorhaben.
Kein Vertrieb. Ein direktes Gespräch mit der Geschäftsführung. Antwort innerhalb eines Werktags.
