Zwei Wege zu DDD. Ein fundamentaler Unterschied.
Ecotone gibt dir ein Runtime-Framework mit Attributes und Message Bus. Jardis erzeugt den Architektur-Code und gibt dir die volle Kontrolle über jede Datei. Beide lösen DDD in PHP. Der Ansatz könnte unterschiedlicher nicht sein.
Frameworks abstrahieren. Aber Abstraktion hat einen Preis.
Runtime-Frameworks für DDD sind leistungsfähig. Aber sie binden dich an ihre Abstraktion, auch wenn dein Projekt darüber hinauswächst.
Dein Domain-Code gehört dem Framework
Ecotone nutzt PHP-Attributes um Commands, Events und Aggregates zu deklarieren. Deine Business-Logik ist mit Framework-Annotationen durchzogen. Willst du Ecotone entfernen, refaktorierst du jede Klasse. Der Domain-Code wird zur Framework-Abhängigkeit.
Was passiert hinter den Attributes?
Attribute-basierte Konfiguration ist kompakt, aber die Infrastruktur passiert unsichtbar. Routing, Handler-Resolution, Serialisierung: das Framework entscheidet. Wenn das Verhalten nicht deinen Erwartungen entspricht, debuggst du fremden Framework-Code.
Messaging-Architektur von Tag eins
Ecotone setzt auf Message Channels als Kommunikationsmodell. Das ist leistungsfähig für Event-Driven Systeme, aber erzwingt eine Architektur-Entscheidung bevor du weißt, ob du sie brauchst. Nicht jede Domain braucht asynchrones Messaging von Anfang an.
Code der dir gehört. Nicht einem Framework.
Jardis erzeugt PHP-Code, den du lesen, ändern und besitzen kannst. Kein Runtime-Framework, keine versteckten Abstraktionen, keine Attribute in deiner Domain.
Erzeugter Code ohne Framework-Abhängigkeit
Der Jardis Builder erzeugt Entities, Aggregates, Commands, Queries und Domain Events als reinen PHP-Code. Keine Framework-Attributes, keine Runtime-Magie. Jede Klasse ist lesbar, testbar und gehört dir. Du kannst Jardis morgen entfernen und der Code funktioniert weiter.
Hexagonale Architektur auf Dateisystem-Ebene
Ecotone steuert Architektur über Attribute-Konventionen zur Laufzeit. Jardis erzwingt hexagonale Architektur physisch durch Package-Strukturen. Bounded Contexts sind eigenständige PHP-Packages. Layer-Grenzen sind Verzeichnisstrukturen, nicht Annotationen. Verstöße sind technisch unmöglich, nicht nur unerwünscht.
Kein Messaging-Overhead für einfache Domains
Nicht jeder Bounded Context braucht Message Channels und Event Sourcing. Jardis erzeugt die Architektur die du definierst: CQRS für komplexe Domains, einfache Repository-Pipelines für unkomplizierte. Du entscheidest pro Domain, nicht das Framework.
Warum Teams erzeugten Code einem Runtime-Framework vorziehen.
Nicht weil Ecotone schlecht ist. Sondern weil Code-Ownership langfristig mehr Kontrolle gibt als Framework-Abstraktion.
Jede Zeile ist dein Code
Kein Framework-Internals-Debugging, keine versteckten Konventionen. Was der Builder erzeugt, liegt als PHP-Dateien in deinem Repository. Neue Entwickler lesen Code, nicht Framework-Docs.
Framework-agnostisch ab der Domain-Schicht
Der erzeugte Code funktioniert mit Laravel, Symfony, oder ohne Framework. Ecotone bindet dich an sein Messaging-Modell. Jardis erzeugt Code, den du in jede PHP-Umgebung einbettest.
Kein Framework-Upgrade-Risiko in der Domain
Deine Domain-Logik hat keine Ecotone-Abhängigkeit, keine Attribute die bei Major-Updates brechen. Der erzeugte Code ist stabiler PHP-Code, unabhängig von Framework-Releasezyklen.
Bereit für DDD in PHP, ohne Runtime-Abhängigkeit?
Auf die WaitlistHäufige Fragen
Antworten auf die wichtigsten Fragen zum Vergleich zwischen Jardis und Ecotone.
Nein. Ecotone ist ein durchdachtes PHP-Framework für Message-Driven Architecture mit CQRS und Event Sourcing. Der Unterschied liegt im Ansatz: Ecotone abstrahiert Infrastruktur zur Laufzeit, Jardis erzeugt sie als PHP-Code der dir gehört. Teams, die volle Code-Ownership und physische Architektur-Grenzen bevorzugen, sind mit Jardis besser bedient.