Directus oder Laravel: Wo gehört die Geschäftslogik hin?

Die Entscheidung beginnt beim Ablauf #

Ein Team braucht eine Oberfläche, um Produkte, Ansprechpartner oder Inhalte zu pflegen. Gleichzeitig sollen Angebote berechnet, Aufträge freigegeben oder Daten mit anderen Systemen abgeglichen werden. Directus kann dafür bereits viel mitbringen. Trotzdem gehört nicht jede fachliche Regel automatisch in einen Flow, und nicht jedes Projekt benötigt zusätzlich Laravel.

Ich würde zuerst zwei Fragen trennen: Welche Daten sollen Menschen bequem bearbeiten können? Und welche Regeln müssen bei jeder Änderung verbindlich gelten? Daraus lässt sich ableiten, ob Directus mit Konfiguration ausreicht, eine Erweiterung sinnvoll ist oder ein eigenes Backend die bessere Grundlage bildet. Die folgenden Beispiele sind Entscheidungshilfen, keine starren technischen Grenzen.

Was Directus im Standard abdeckt #

Directus stellt eine Verwaltungsoberfläche, das Data Studio, und APIs für den Zugriff auf Daten bereit. Damit lässt sich etwa ein Produktkatalog pflegen und für eine Website bereitstellen. Datenmodell, Oberfläche und Zugriffe müssen zum Projekt passend eingerichtet werden; eine individuelle Kundenoberfläche entsteht dadurch noch nicht automatisch.

• Collections, Felder und Beziehungen für strukturierte Daten konfigurieren.
• Datensätze und Dateien im Data Studio pflegen, suchen und filtern.
• Daten über REST oder GraphQL in andere Anwendungen einbinden.
• Benutzer, Rollen und Policies für den Zugriff einrichten.
• Zugriffe auf bestimmte Datensätze und Felder begrenzen sowie Validierungen und Vorgabewerte festlegen.

Die Directus-Übersicht zu APIs und Data Studio beschreibt die Grundbausteine. Die Dokumentation zur Zugriffskontrolle erläutert die feiner abgestuften Rechte. So kann beispielsweise ein Redaktionsteam Inhalte bearbeiten, während andere Nutzer nur freigegebene Datensätze lesen dürfen.

Wenn dein Projekt hauptsächlich strukturierte Datenpflege und deren Bereitstellung benötigt, würde ich diese Möglichkeiten zuerst ausschöpfen. „Standard“ bedeutet dabei vorhandene Produktfunktionen; Einrichtung, Betrieb und die Anbindung deiner Website bleiben Projektarbeit.

Wie weit sich Abläufe mit Flows konfigurieren lassen #

Mit Flows lassen sich Ereignisse, Bedingungen und Aktionen verbinden. Ein neuer Datensatz kann etwa eine Benachrichtigung auslösen; ein geplanter Lauf kann Daten verarbeiten oder einen anderen Dienst aufrufen. Auch eine einfache Freigabe lässt sich mit Statusfeld, passenden Berechtigungen und ergänzenden Flows gestalten. Die Directus-Beschreibung des Workflow-Editors nennt Datenänderungen, Zeitpläne, Webhooks und API-Aufrufe als Bausteine.

Bei einer überschaubaren Benachrichtigung oder Datenübergabe ist das oft ein sinnvoller Einstieg. Wenn jedoch zahlreiche Ausnahmen, Wiederholungen und voneinander abhängige Zustände entstehen, würde ich prüfen, ob der Ablauf noch verständlich getestet und geändert werden kann. Eine bestimmte Anzahl an Flow-Schritten ist dafür kein verlässliches Kriterium.

Eine verpflichtende Prüfung muss vor dem Speichern beziehungsweise vor der fachlichen Freigabe greifen. Eine nachträgliche Benachrichtigung kann eine bereits erfolgte Änderung nicht verhindern. Ebenso sollten langsame externe Aufrufe nicht unüberlegt den Speichervorgang blockieren. Diese Entscheidung betrifft den Aufbau des Ablaufs, unabhängig davon, ob er visuell oder in Code umgesetzt wird.

Wann individuelle Directus-Erweiterungen sinnvoll sind #

Eigene Programmierung wird nötig, wenn vorhandene Funktionen und Konfiguration die konkrete Anforderung nicht abbilden. Das kann ein spezielles Eingabefeld, eine individuelle Berechnung, eine zusätzliche Prüfung oder ein eigener API-Endpunkt sein. Auch ein Skript innerhalb eines Flows ist bereits eigener Code und sollte entsprechend gepflegt werden.

Directus lässt sich dafür erweitern. Ein Interface kann eine besondere Eingabe im Data Studio ermöglichen, eine eigene Operation einen wiederverwendbaren Flow-Baustein bereitstellen und ein Endpoint einen individuellen API-Aufruf anbieten. Hooks reagieren auf Ereignisse: Filter können Daten vor dem Ereignis prüfen, verändern oder den Vorgang abbrechen; Actions reagieren danach. Diese Unterscheidung beschreibt die Dokumentation zu Directus-Hooks.

Für eine klar begrenzte, eng mit der Datenpflege verbundene Regel würde ich eine Erweiterung prüfen. Dabei gehören Berechtigungen, automatisierte Tests und die Kompatibilität bei Directus-Updates zur Umsetzung. Allein der Bedarf an Geschäftslogik ist noch kein Grund, ein zweites Backend einzuführen.

Wann ich eher Laravel einsetzen würde #

Laravel würde ich als zentrale Anwendung in Betracht ziehen, wenn fachliche Vorgänge das Projekt bestimmen, zum Beispiel:

• Angebote mit mehreren Preisregeln.
• Aufträge mit verbindlichen Zustandswechseln.
• Reservierungen, die auch bei gleichzeitigen Anfragen korrekt bleiben müssen.

Dann sind die Daten nicht nur zu pflegen; Änderungen müssen einem festgelegten Prozess folgen.

Ein eigenes Laravel-Backend erlaubt es, solche Regeln in einer gemeinsamen Codebasis mit passenden Tests zu organisieren. Laravel bietet unter anderem Datenbanktransaktionen und Queues für Hintergrundaufgaben. Die fachliche Korrektheit entsteht durch die Implementierung: geeignete Sperren, Eindeutigkeitsregeln und wiederholbare Verarbeitung liefert ein Framework nicht automatisch für deinen Geschäftsfall.

Das ist eine Architekturentscheidung, keine Aussage, dass Directus komplexe Logik grundsätzlich nicht umsetzen könnte. Für mich zählen die vorhandenen Kenntnisse im Team, die Änderbarkeit der Regeln und der Aufwand für Tests und Betrieb. Wenn das Data Studio kaum Nutzen bringt und ohnehin eine individuelle Oberfläche benötigt wird, kann Laravel allein die einfachere Gesamtanwendung sein. Oberfläche und Verwaltungsfunktionen müssen dann separat geplant werden.

Wann Directus plus Laravel gut zusammenpasst #

Die Kombination ist interessant, wenn sowohl komfortable Datenpflege als auch umfangreiche fachliche Abläufe wichtig sind. Ein mögliches Beispiel: Das Team pflegt Produkttexte, Bilder und redaktionelle Merkmale in Directus. Laravel übernimmt Angebotsberechnung, Reservierung und Auftragsabschluss. Eine Website oder ein Portal nutzt die jeweils dafür vorgesehenen APIs.

Beim Erstellen eines Angebots liest Laravel die benötigten Produktinformationen und hält die relevanten Werte am Angebot fest. Eine spätere Änderung eines Produkttexts oder einer Kondition darf ein bereits verbindliches Angebot nicht stillschweigend verändern. Welche Daten eine solche Momentaufnahme benötigen, wird fachlich festgelegt.

Auch das Data Studio kann Ausgangspunkt einer Aktion sein: Eine individuelle Schaltfläche stößt beispielsweise eine Freigabe im Laravel-Backend an. Laravel prüft die Identität, die Berechtigung und den aktuellen Zustand selbst. Directus kann das Ergebnis anschließend anzeigen. Die Schaltfläche ersetzt dabei nicht die Prüfung auf dem Server.

Dieser Aufbau lohnt sich, wenn beide Systeme einen klaren eigenen Nutzen haben. Dafür entstehen zusätzliche Aufgaben bei Authentifizierung, Schnittstellen, Fehlerbehandlung, Deployment und Monitoring. Für einen kleinen Katalog mit wenigen Benachrichtigungen würde ich diesen Aufwand nicht automatisch einplanen.

Die wichtigste Regel: Schreibwege klar trennen #

Für jedes fachlich relevante Datum sollte feststehen, welches System es verbindlich verwaltet. Wenn Laravel einen Auftrag nur nach erfolgreicher Prüfung abschließen darf, darf derselbe Status nicht über ein frei editierbares Directus-Feld oder dessen allgemeine API geändert werden können. Solche Felder sollten dort für die betroffenen Nutzer nur lesbar sein; fachliche Aktionen laufen über den vorgesehenen Dienst.

Für diesen Aufbau würde ich getrennte Datenbereiche und explizite APIs bevorzugen. Zwei Anwendungen, die dieselben Tabellen beliebig ändern, können gegenseitig ihre Regeln umgehen: Ein direkter Datenbankzugriff durch Laravel durchläuft keine Directus-Hooks oder Directus-Berechtigungsprüfung. Umgekehrt führt eine Änderung durch Directus keine Laravel-Modellereignisse oder Laravel-Policies aus. Bei einer gemeinsamen Datenbank müssen deshalb Schreibrechte und die Verantwortung für Schemaänderungen besonders eindeutig sein.

Zwischen zwei Diensten gibt es durch einen HTTP-Aufruf keine gemeinsame lokale Datenbanktransaktion. Bei einem Ausfall braucht es einen nachvollziehbaren Zwischenzustand, eine sichere Wiederholung oder einen Abgleich. Eine Rückmeldung wie „Freigabe wird verarbeitet“ ist dann ehrlicher als eine Erfolgsmeldung, bevor der zuständige Dienst den Vorgang bestätigt hat. Mehr zur Vorbereitung solcher Abläufe findest du unter Schnittstellen planen.

Welche Variante passt zu deinem Projekt? #

• Directus konfigurieren: Strukturierte Inhalte und Stammdaten, passende Verwaltungsoberfläche und überschaubare automatisierte Abläufe.
• Directus individuell erweitern: Die Plattform passt bereits; einzelne Eingaben, Prüfungen oder Integrationen benötigen eigenen Code.
• Laravel einsetzen: Fachliche Vorgänge und eine individuelle Anwendung stehen im Mittelpunkt; die fertige Directus-Verwaltung bringt wenig zusätzlichen Nutzen.
• Directus und Laravel kombinieren: Datenpflege und Geschäftsprozesse haben jeweils genug Umfang, um getrennte Zuständigkeiten und den zusätzlichen Betrieb zu rechtfertigen.

Für eine erste Einordnung würde ich einen konkreten Vorgang durchgehen:

• Wer startet ihn?
• Welche Daten werden dabei geändert?
• Welche Regeln dürfen nie verletzt werden?
• Was passiert bei einem Fehler?

Daran zeigt sich meist besser als an einer Funktionsliste, wo Konfiguration endet und welche Programmierung sinnvoll ist.

Ich unterstütze dich bei Directus und individuellen Erweiterungen, bei Laravel-Backends und bei der Verbindung beider Systeme. Über die Projektanfrage kannst du deinen aktuellen Ablauf und die offenen Architekturfragen beschreiben.