Die Schnittstelle steht. Bevor die Logik geschrieben wird.
Die meisten Teams entscheiden die Schnittstelle erst beim Implementieren. Jardis dreht das um: Die Domain API entsteht typisiert aus dem Schema, zusammen mit dem Domänencode. Die API-Schicht jedes Bounded Contexts steht fest, bevor die erste Business-Logik fällt.
API-Docs die hinterherhinken.
Der Code ist fertig, die API läuft. Jetzt fehlen noch die Docs. Bis die stimmen, hat sich die Schnittstelle bereits zweimal geändert.
Frontend wartet auf Backend-Entscheidungen
Der Backend-Entwickler entscheidet spontan wie der Endpunkt aussieht. Das Frontend-Team blockiert. Stundenlange Abstimmungen ersetzen keine definierten Contracts.
API-Docs sind immer veraltet
Swagger-Files werden manuell gepflegt. Nach drei Sprints stimmt die Dokumentation nicht mehr mit der Realität überein. Jeder weiss es, niemand hat Zeit zum Nachziehen.
Schnittstellen entstehen im Nachhinein
Das API-Design ist ein Nebenprodukt der Implementierung. Fehler im Contract fallen erst auf, wenn Frontend und Backend zusammenkommen. Dann ist ein Umbau teuer.
Wie Jardis API-First Architektur umsetzt.
Jardis erzeugt die Domain API als Teil des Domänencodes. Nicht danach, nicht separat. Gleichzeitig.
Domain-Schema als Ausgangspunkt
Ihr definiert euer Datenbankschema und die Aggregate-Struktur. Der Builder versteht, welche Operationen welcher Bounded Context exponieren soll. Das Domain-Modell ist die einzige Quelle der Wahrheit für Code und API.
Die Domain API entsteht mit dem Domänencode
Jardis erzeugt die Domain API zusammen mit Entities, Commands, Queries und Domain Events. Jeder Bounded Context exponiert seine Use Cases als typisierte Commands und Queries. Die Schnittstelle beschreibt exakt, was der Builder implementiert. Keine Lücke zwischen Definition und Realität.
Frontend und Backend starten gleichzeitig
Die Schnittstelle steht fest, aus dem Modell. Das Backend-Team implementiert die Business-Logik in den erzeugten Strukturen, das Frontend kennt jede Operation und ihre Typen von Anfang an. Keine spontan erfundenen Endpunkte, keine Überraschungen beim Zusammenführen.
Warum Teams API-First mit Jardis umsetzen.
Weil Contracts keine Dokumentationsaufgabe sein sollten, sondern ein Designprinzip.
API-Design vor der Implementierung
Die Domain API entsteht im selben Builder-Lauf wie der Domänencode. Die Schnittstelle ist definiert, bevor die erste Business-Logik geschrieben wird.
Docs die nicht veralten können
Die API-Schicht ist kein separates Dokument. Sie ist erzeugter Output aus demselben Schema wie der PHP-Code. Ändert sich das Modell, ändern sich API und Code gemeinsam.
Frontend und Backend entkoppelt
Die API-Schicht ist aus dem Modell festgelegt, mit typisierten Ein- und Ausgaben. Backend-Teams befüllen die erzeugten Strukturen mit Business-Logik, das Frontend kennt die Schnittstelle von Anfang an. Beide arbeiten gleichzeitig, ohne aufeinander zu warten.
Bereit, API-Design als Designprinzip zu behandeln?
Auf die WaitlistHäufige Fragen
Antworten zur API-First Architektur mit Jardis.
Der Builder erzeugt die Domain API: pro Bounded Context eine typisierte Facade mit Commands und Queries, typisierten DTOs und Response-Objekten. Diese Schnittstelle entsteht zusammen mit dem PHP-Domänencode in einem einzigen Builder-Lauf. Den Transport nach außen, etwa HTTP, verdrahtest du im Adapter.