Hexagonale Architektur. Per Default, nicht per Zufall.
Ports & Adapters korrekt umzusetzen kostet Wochen und tiefes Architektur-Know-how. Jardis generiert 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 generiert 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.
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 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
Generierte 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 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 zu hexagonaler Architektur mit Jardis.
Jardis generiert 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.