Hexagonale Architektur mit Symfony 8: Wann lohnt sie sich?

Hexagonale Architektur mit Symfony 8: Wann lohnt sie sich?

Wer Symfony-Projekte für wachsende Unternehmen betreut, kennt das Gespräch. Irgendwann sagt jemand: "Wir sollten das nach Domain-Driven Design aufbauen." Manchmal hat er recht. Manchmal kostet es doppelt so viel und liefert dasselbe Ergebnis wie ein Standard-Setup. Den Unterschied zu kennen, ist keine akademische Frage, sondern eine handwerkliche.

Robin Chalas, Symfony Core Team Member und CEO von baksla.sh, hat seinen Talk "Symfony 8: The Hexagonal Track" sowohl beim SymfonyDay Montreal als auch beim SymfonyOnline June 2026 (11.-12. Juni) gezeigt. Die Kernthese: Strukturierung einer Applikation rund um die Domäne statt rund um das Framework fühlte sich früher an wie "swimming against the current". Das ändert sich jetzt, dank PHP 8.4-Features und Symfony-8-Entwicklungen, die sich "natürlich an hexagonales Denken und taktische DDD-Patterns anschmiegen, ohne Workarounds, ohne Ringen mit den Werkzeugen".

Was macht das konkret aus? Und: Lohnt es sich für Ihr Projekt?

Was hat sich mit Symfony 8 konkret verändert?

Der entscheidende Schritt: PHP 8.4 bringt Native Lazy Objects, was bedeutet, dass Doctrine-Entities jetzt echte Readonly-Aggregate sein können, ohne Performance-Kompromisse beim Lazy-Loading. Das war früher der häufigste Bruchpunkt zwischen DDD-Purismus und Doctrine-Pragmatismus.

Was steckt hinter "hexagonalem Denken"?

Hexagonale Architektur (auch Ports & Adapters) ist eine Idee aus den 2000er Jahren: Die Geschäftslogik (Domain) steht im Mittelpunkt. Alles andere (Datenbank, HTTP, CLI, externe APIs) wird über Ports (Interfaces) angebunden. Adapters implementieren diese Interfaces.

Das klingt abstrakt. Konkret bedeutet es: Ihr Bestellprozess-Code weiß nicht, ob die Daten in MySQL, PostgreSQL oder einem In-Memory-Repository gespeichert werden. Er arbeitet nur mit dem OrderRepositoryInterface. Wer ihn implementiert, entscheidet Symfony über DI.

// Port: das Interface in der Domäne
namespace App\Domain\Order;

interface OrderRepositoryInterface
{
public function findById(OrderId $id): Order;
public function save(Order $order): void;
}

// Adapter: die Doctrine-Implementierung in der Infrastruktur-Schicht
namespace App\Infrastructure\Persistence;

class DoctrineOrderRepository implements OrderRepositoryInterface
{
public function __construct(private EntityManagerInterface $em) {}

public function findById(OrderId $id): Order {
return $this->em->find(Order::class, $id->value());
}
}

// Symfony DI verbindet Port und Adapter:
# config/services.yaml
App\Domain\Order\OrderRepositoryInterface: '@App\Infrastructure\Persistence\DoctrineOrderRepository'

Was früher Boilerplate war, ist jetzt sauber: Symfony 8 verbindet Port und Adapter über reguläres Autowiring. Keine Custom-Compiler-Passes, keine manuelle Factory.

Welche taktischen DDD-Patterns profitieren am meisten?

Aggregate Roots mit Readonly Classes: Ein Order-Aggregate als Readonly Class erzwingt, dass der Zustand nur über Domain-Methoden verändert wird. Keine fremde Methode kann einfach $order->status = 'shipped' schreiben. Das war früher mit Doctrine-Entities schwierig, weil Doctrine mutable Objekte bevorzugt. PHP 8.4 Native Lazy Objects lösen das.

Domain Events über Messenger: Wenn ein Bestellstatus sich ändert, emittiert das Aggregate einen OrderShippedEvent. Symfony Messenger verteilt ihn an alle Handler (Email-Versand, Lager-Update, Analytics). Die Domäne kennt die Handler nicht, die Handler kennen sich nicht gegenseitig.

Value Objects als Backed Enums: OrderStatus war früher eine Klasse mit Konstanten und Validierung. Jetzt ist es ein Backed Enum: typsicher, in Doctrine direkt verwendbar, keine zusätzliche Library.

// Value Object als Backed Enum (PHP 8.1+, nativ in Symfony 8)
enum OrderStatus: string
{
case Pending = 'pending';
case Paid = 'paid';
case Shipped = 'shipped';
case Cancelled = 'cancelled';

public function canTransitionTo(self $new): bool
{
return match($this) {
self::Pending => in_array($new, [self::Paid, self::Cancelled]),
self::Paid => $new === self::Shipped,
default => false,
};
}
}
// Domänen-Logik (Transitionen) sitzt im Enum, nicht im Service.

Wann lohnt sich hexagonale Architektur wirklich?

Hier ist die Frage, die in Konferenz-Talks oft ausgespart wird. Ein Kommentar unter dem SymfonyDay-Montreal-Blogpost formuliert es direkt: "From 2022 to 2025, I worked on a Symfony project where the lead developer chose DDD simply because he liked it. We spent more than double the budget and delivered the same result a standard Symfony setup would have produced."

Das ist kein Einzelfall. Aus meiner Erfahrung mit Symfony-Projekten in der deutschen Agentur-Landschaft sehe ich das Muster regelmäßig: DDD wird eingesetzt, weil es architektonisch interessant ist, nicht weil die Domänen-Komplexität es erfordert.

Wann ist hexagonale Architektur die richtige Wahl?

Geeignet wenn: Die Domänen-Logik wächst und die Regeln kommen aus dem Business ("Bestellungen unter 50€ können nicht rückerstattet werden, wenn sie älter als 14 Tage sind, außer bei Qualitätsmängeln"). Wenn das Team wächst und verschiedene Teams verschiedene Bounded Contexts ownen. Wenn die Infrastruktur sich ändern kann (Datenbank-Migration, Cloud-Provider-Wechsel) ohne die Domäne anzufassen.

Nicht geeignet wenn: Der Hauptanwendungsfall ist CRUD. Wenn das Team klein ist (2-3 Entwickler) und die Domäne stabil. Wenn die Deliverable-Geschwindigkeit wichtiger ist als langfristige Wartbarkeit. Wenn das Team keine DDD-Erfahrung hat und das Projekt die Lernkurve nicht tragen kann.

Der pragmatische Mittelweg: Taktische DDD-Elemente ohne den vollen hexagonalen Stack. Backed Enums für Status-Transitions. Value Objects für Identifier. Domain Events für Side-Effects. Repository-Interfaces für testbare Use-Cases. Das sind keine Architektur-Entscheidungen, die Wochen Overhead kosten. Das sind Code-Qualitäts-Entscheidungen, die sich sofort amortisieren.

Aus der Praxis: Was ich bei Bestandssystemen sehe

Robin Chalas trägt dabei seine "zwei Hüte" bewusst: Core-Team-Mitglied und DDD-Praktiker. Das ist genau die Kombination, die den Talk interessant macht. Wer will, kann sich die Aufzeichnung von SymfonyOnline June 2026 auf dem offiziellen Symfony-YouTube-Kanal anschauen.

Zusammenfassung

Symfony 8 + PHP 8.4 macht hexagonale Architektur und taktische DDD-Patterns ohne Workarounds möglich. Readonly Classes, Native Lazy Objects, Backed Enums und Symfony DI arbeiten zusammen.

Die drei sofort nützlichen Patterns: Backed Enums für Status-Transitions, Value Objects als Readonly Classes, Domain Events über Symfony Messenger.

Der ehrliche Vorbehalt: Hexagonale Architektur für CRUD-Projekte ist Overengineering. Den DDD-Kommentar aus dem Symfony-Blog-Kommentar ("doppeltes Budget, gleiches Ergebnis") sollte jeder im Kopf haben, bevor er DDD für ein Projekt vorschlägt.

Der pragmatische Mittelweg: Taktische DDD-Elemente ohne den vollen Stack. Das amortisiert sich schnell und erzeugt keinen Overhead.