Der Contract steht. Bevor Code geschrieben wird.
Die meisten Teams schreiben erst den Code und dann die Docs. Jardis dreht das um: API Contracts in OpenAPI und gRPC entstehen zusammen mit dem Domänencode, sodass Frontend und Backend parallel loslegen können.
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 generiert OpenAPI und gRPC Contracts 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 Contract.
Contracts entstehen mit dem Domänencode
Jardis generiert OpenAPI-Specs und gRPC-Service-Definitionen zusammen mit Entities, Commands, Queries und Domain Events. Der Contract beschreibt exakt, was der Builder implementiert. Keine Lücke zwischen Spezifikation und Realität.
Frontend und Backend starten gleichzeitig
Der Contract steht. Das Frontend-Team entwickelt gegen die OpenAPI-Spec, das Backend-Team implementiert die Business-Logik in den generierten Strukturen. Keine Blockaden, keine Überraschungen beim Zusammenführen.
Sieh selbst, was aus drei Dateien entsteht.
Drei Definitionsdateien rein, ein kompletter Bounded Context raus. Klick dich durch den generierten Code.
# Database Schema — Sales Bounded Context
# This file defines the persistent storage structure.
schema:
domain: ECommerce
boundedContext: Sales
tables:
order:
columns:
id:
type: integer
primary: true
autoIncrement: true
public_id:
type: uuid7
unique: true
customer_email:
type: string
length: 255
status:
type: string
length: 32
default: "draft"
total_amount:
type: integer
currency:
type: string
length: 3
default: "EUR"
created_at:
type: datetime
updated_at:
type: datetime
nullable: true
order_item:
columns:
id:
type: integer
primary: true
autoIncrement: true
order_id:
type: integer
foreignKey:
table: order
column: id
onDelete: cascade
product_name:
type: string
length: 255
sku:
type: string
length: 64
quantity:
type: integer
unit_price:
type: integer
line_total:
type: integer
Warum Teams API-First mit Jardis umsetzen.
Weil Contracts keine Dokumentationsaufgabe sein sollten, sondern ein Designprinzip.
API-Design vor der Implementierung
OpenAPI- und gRPC-Contracts entstehen im selben Builder-Lauf wie der Domänencode. Das Interface ist definiert, bevor die erste Business-Logik geschrieben wird.
Docs die nicht veralten können
Der Contract ist kein separates Dokument. Er ist generierter Output aus demselben Schema wie der PHP-Code. Ändert sich das Modell, ändern sich Contract und Code gemeinsam.
Frontend und Backend entkoppelt
Frontend-Teams mocken gegen die OpenAPI-Spec. Backend-Teams befüllen die generierten Strukturen mit Business-Logik. Beide arbeiten gleichzeitig, ohne aufeinander zu warten.
Bereit, API-Design als Designprinzip zu behandeln?
Auf die WaitlistStruktur kostet weniger als Chaos.
Teste Jardis 7 Tage kostenlos
Lass Jardis an deiner echten Domäne los. Discovery, Struktur und dein erster Platform Build.
Join WaitlistDie komplette DDD-Architektur mit allen Klassen und Contracts. Dein Team schreibt Features, nicht Infrastruktur.
Join WaitlistDie komplette Business-Logik mit Handlern, Validierung und Pipelines. Was früher ein Sprint war, ist jetzt ein Build.
Join WaitlistMehr als 20 Platform Builds pro Monat?
Lass uns sprechenSei dabei, wenn Jardis startet.
Trag dich ein. Du bekommst Zugang, sobald wir live gehen. Inklusive kostenlosem Trial.
Neugierig, wie Jardis funktioniert?
Jardis entdeckenHäufige Fragen
Antworten zur API-First Architektur mit Jardis.
Der Builder generiert OpenAPI 3.x Specs und gRPC Service-Definitionen (.proto-Dateien) für jeden Bounded Context. Beide entstehen zusammen mit dem PHP-Domänencode in einem einzigen Builder-Lauf. Keine manuelle Nacharbeit.