Use Cases

Konkrete Einsatzszenarien für Jardis

Monolith modernisieren. Ohne alles neu zu schreiben.

PHP-Monolithen schrittweise modernisieren. Jardis erzeugt die DDD-Zielarchitektur, damit euer Team Bounded Context für Bounded Context migrieren kann.

Mehr erfahren

Microservices extrahieren. Service für Service.

Microservices aus Monolith extrahieren: Jardis erzeugt die Domain API und Zielarchitektur pro Service. Schrittweise, kein Big-Bang-Rewrite.

Mehr erfahren

Greenfield-Projekte richtig starten. Mit DDD in PHP.

Jardis erzeugt produktionsreife DDD-Architektur ab Tag 1. Bounded Contexts, CQRS, Domain Events und Repository Pipeline. Kein Prototyp-Rewrite nötig.

Mehr erfahren

Ein Deployment. Klare Module. Keine Microservice-Kopfschmerzen.

PHP-Monolith intern strukturieren ohne Microservices. Jardis erzeugt saubere Bounded-Context-Module mit klaren Domain-Grenzen. Ein Deployment, klare Struktur.

Mehr erfahren

Drei Teams, eine Codebasis, ein Merge-Konflikt zu viel.

Mehrere Teams, eine Codebasis, null Chaos: Jardis macht Bounded Contexts zu physischen Team-Grenzen. Unabhängige Deployments ohne Koordinations-Overhead.

Mehr erfahren

Die Schnittstelle steht. Bevor die Logik geschrieben wird.

API-First Architektur in PHP: Jardis erzeugt die Domain API typisiert pro Bounded Context, direkt aus dem Schema. Die Schnittstelle steht, bevor die Business-Logik fällt.

Mehr erfahren

Greenfield Microservices von Tag 1. Ohne den Distributed Monolith.

Greenfield Microservices ohne Distributed Monolith: Jardis erzeugt Bounded Contexts, die Domain API und Domain Events pro Service ab Tag 1.

Mehr erfahren

Brownfield oder Greenfield: der Einstiegspunkt bestimmt die Strategie

DDD-Architektur-Erzeugung ist kein Werkzeug das ausschließlich auf der grünen Wiese funktioniert. Die Mehrheit der produktiven PHP-Systeme hat eine Geschichte: gewachsene Codebasis, Framework-Abhängigkeiten im falschen Layer, fehlende Domain-Grenzen. Brownfield-Migration bedeutet nicht, das System neu zu schreiben — es bedeutet, neue Funktionalität auf einer sauberen Architektur zu bauen, während das bestehende System läuft.

Für Greenfield-Projekte ist der Vorteil anders gelagert: die Architektur ist von Sprint 1 an konsistent. Neue Bounded Contexts werden erzeugt statt hand-codiert, was bedeutet dass das Team sofort mit Business-Logik beginnt statt mit Infrastruktur. Multi-Team-Entwicklung profitiert davon, dass jeder Kontext identisch aufgebaut ist — Onboarding auf einen neuen Bounded Context dauert Stunden statt Wochen.

Microservices-Extraktion, modularer Monolith, API-First-Entwicklung: jedes Szenario hat eigene Anforderungen an den Zeitpunkt und die Reihenfolge der Erzeugung. Die folgenden Seiten beschreiben für jeden Use Case den konkreten Ablauf — welche Kontexte wann erzeugt werden, wie die Integration in bestehende Systeme aussieht und wann welcher Ansatz die bessere Wahl ist.