Hexagonale Architektur. Per Default, nicht per Zufall.
Ports & Adapters korrekt umzusetzen kostet Wochen und tiefes Architektur-Know-how. Jardis erzeugt die komplette hexagonale Struktur für jeden Bounded Context automatisch: keine Abweichungen, keine Diskussionen über Ordnerstrukturen.
Hexagonale Architektur: alle wollen sie, kaum jemand setzt sie korrekt um.
Das Pattern ist seit 20 Jahren bekannt. Trotzdem scheitern die meisten Teams an der konsequenten Umsetzung.
Theorie klar, Praxis nicht
Jeder im Team versteht Ports & Adapters konzeptionell. Aber wo genau liegt die Grenze zwischen Application Service und Domain Service? Ab wann braucht ein Port ein eigenes Interface? Die Antworten variieren pro Entwickler.
Layer-Grenzen erodieren über Zeit
Sprint 1: saubere Trennung. Sprint 10: ein Adapter greift direkt auf die Domain-Logik zu, weil es schneller ging. Sprint 20: die Architektur existiert nur noch im Wiki, nicht im Code.
Onboarding wird zum Architektur-Seminar
Neue Entwickler müssen erst die hausinternen Konventionen lernen, bevor sie produktiv werden. Jedes Team interpretiert hexagonale Architektur anders. Wissen über Architektur-Entscheidungen lebt in Köpfen, nicht im Code. Die Einarbeitungszeit frisst Wochen.
Wie Jardis hexagonale Architektur löst.
Nicht als Guideline in Confluence, sondern als physische Struktur im Code.
Jeder Bounded Context folgt derselben Struktur
Jardis erzeugt für jeden Bounded Context die komplette hexagonale PHP-Architektur: Ports als Interfaces, Adapter als Implementierungen, Application Services als Orchestratoren, plus CQRS mit getrennten Commands und Queries. Die Struktur ist identisch, egal ob es der erste oder der zwanzigste Context ist.
Die Domain-Schicht bleibt frei von Infrastruktur
Entities, Value Objects und Domain Events leben in einer eigenen Schicht ohne Abhängigkeiten nach außen. Der Builder stellt sicher, dass keine Infrastruktur-Imports in die Domain gelangen. Nicht durch Code Reviews, sondern durch die Struktur selbst.
Eine Architektur für das gesamte System
Ob drei oder dreißig Bounded Contexts: jeder folgt dem gleichen hexagonalen Pattern. Neue Teammitglieder verstehen einen Context und verstehen alle. Keine Sonderlösungen, keine historisch gewachsenen Abweichungen, keine teamspezifischen Interpretationen der Architektur.
Warum Teams mit Jardis auf hexagonale Architektur setzen.
Weil die Architektur nicht mehr vom Erfahrungslevel einzelner Entwickler abhängt.
Gleiche Architektur in jedem Bounded Context
Kein Bounded Context ist ein Sonderfall. Die hexagonale Struktur ist identisch, von der Ordnerstruktur bis zu den Dependency-Regeln. Wer einen Context kennt, kennt alle.
Neue Contexts in Minuten statt Wochen
Schema definieren, Builder starten. Die gesamte hexagonale Architektur steht sofort. Keine manuellen Ordnerstrukturen, keine Copy-Paste-Fehler, keine Architektur-Reviews für repetitiven Strukturcode.
Architektur die nicht erodiert
Erzeugte Strukturen driften nicht. Jeder neue Bounded Context ist genauso sauber wie der erste. Die Architektur bleibt wartbar, auch nach zwei Jahren und zwanzig Contexts.
Hexagonale Architektur als Standard, nicht als Ideal?
Auf die WaitlistHäufige Fragen
Antworten zu hexagonaler Architektur mit Jardis.
Jardis erzeugt die hexagonale PHP-Schichtung pro Bounded Context: Ports als Interfaces, Adapter als Implementierungen, Application Services als Orchestratoren. Die Domain-Schicht bleibt frei von Infrastruktur-Imports. Dazu die Entity-Hierarchie mit Domain Entity, Aggregate Entity und BoundedContext Layer. Euer Team schreibt nur die Business-Logik in der Domain.