{"id":37901,"date":"2023-10-30T11:55:12","date_gmt":"2023-10-30T10:55:12","guid":{"rendered":"https:\/\/www.happycoders.eu\/?p=37901"},"modified":"2026-06-17T08:31:12","modified_gmt":"2026-06-17T06:31:12","slug":"hexagonale-architektur-quarkus","status":"publish","type":"post","link":"https:\/\/www.happycoders.eu\/de\/software-craftsmanship\/hexagonale-architektur-quarkus\/","title":{"rendered":"Hexagonale Architektur mit Quarkus [Tutorial]"},"content":{"rendered":"\n

In diesem Artikel zeige ich dir, wie wir die Demo-Anwendung, die wir in den beiden vorangegangenen Teilen dieser Tutorial-Serie unter Verwendung der hexagonalen Architektur implementiert haben, in eine Quarkus-Anwendung migrieren \u2013 und das alles, ohne eine einzige Zeile Code im Anwendungskern zu \u00e4ndern.<\/p>\n\n\n\n

R\u00fcckblick<\/h2>\n\n\n\n

In Teil zwei dieser Artikelserie haben wir eine Java-Anwendung nach hexagonaler Architektur implementiert<\/a>, und in Teil drei haben wir diese um einen zus\u00e4tzlichen Datenbank-Adapter erweitert<\/a>, um die Daten in einer relationalen Datenbank zu persistieren, anstatt sie fl\u00fcchtig im Arbeitsspeicher zu halten.<\/p>\n\n\n\n

Bisher haben wir noch kein Application Framework eingesetzt. Stattdessen haben wir einen simplen Dependency-Injection-Mechanismus selbst implementiert und alle APIs wie Jakarta Persistence und Jakarta RESTful Web Services sowie deren Implementierungen wie Hibernate und RESTEasy direkt angebunden. Daf\u00fcr war einiges an Boilerplate-Code n\u00f6tig (z. B. f\u00fcr das Bootstrapping und das Transaktionsmanagement).<\/p>\n\n\n\n

Die folgende Grafik zeigt die Architektur unserer Anwendung:<\/p>\n\n\n

\n
\"Hexagonale<\/figure>\n<\/div>\n\n\n

Falls du dir noch einmal die Grundlagen der hexagonalen Architektur<\/a> in Erinnerung rufen willst, kannst du dies im soeben verlinkten ersten Teil der Serie tun.<\/p>\n\n\n\n

Das Ergebnis der bisherigen Arbeit findest du im main<\/code>-Branch dieses GitHub-Repositories<\/a>.<\/p>\n\n\n\n

Worum geht es in diesem Teil?<\/h2>\n\n\n\n

In diesem vierten Teil werden wir die einzelnen Anbindungen der Libraries durch ein Application Framework ersetzen und einiges an Boilerplate-Code entfernen k\u00f6nnen.<\/p>\n\n\n\n

Wir setzen in diesem Teil Quarkus<\/a> ein, da auch Quarkus auf Standard-Libraries wie Jakarta RESTful Web Services setzt, anstatt auf eigene Implementierungen wie es das Spring-Framework tut. Das wird die Migration vereinfachen. Spring werden wir im n\u00e4chsten Teil dieser Serie behandeln.<\/p>\n\n\n\n

Auch in diesem Teil werden wir, wie schon im vorherigen Teil, nicht eine einzige Zeile Code im Kern der Anwendung \u2013 also in den model<\/code>- und application<\/code>-Modulen \u2013 ver\u00e4ndern m\u00fcssen.<\/p>\n\n\n\n

Wir werden Schritt f\u00fcr Schritt vorgehen, wobei die Anwendung nach jedem Schritt lauff\u00e4hig sein wird:<\/p>\n\n\n\n

    \n
  1. Zun\u00e4chst werden wir die Quarkus-Dependencies einf\u00fcgen und die direkten Dependencies zu denjenigen Libraries, die von Quarkus mitgebracht werden, entfernen.<\/li>\n\n\n\n
  2. Dann werden wir das adapter<\/code>-Modul an Quarkus anpassen, indem wir den Dependency-Injection-Mechanismus von Quarkus verwenden werden anstatt die Abh\u00e4ngigkeiten manuell zu injizieren.<\/li>\n\n\n\n
  3. Im dritten Schritt werden wir das gleiche f\u00fcr das bootstrap<\/code>-Modul machen.<\/li>\n\n\n\n
  4. Und im letzten Schritt werden wir die selbst implementierte Transaktionsverwaltung und den Zugriff auf die Datenbank durch die @Transactional<\/code>-Annotation und die Verwendung von Panache-Repositories umstellen.<\/li>\n<\/ol>\n\n\n\n

    Starten wir mit Schritt 1\u2026<\/p>\n\n\n\n

    Schritt 1: Ersetzen der Dependencies<\/h2>\n\n\n\n

    Im ersten Schritt werden wir die in den pom.xml<\/code>-Dateien definierten Dependencies anpassen, ohne etwas am Java-Code zu \u00e4ndern. So bleibt unsere Anwendung zun\u00e4chst ohne das Application Framework lauff\u00e4hig, hat aber schon einmal ein aufger\u00e4umtes Set an Dependencies.<\/p>\n\n\n\n

    Anpassung der Eltern-pom.xml<\/h3>\n\n\n\n

    Wir definieren zun\u00e4chst im <properties><\/code>-Block der Eltern-pom.xml<\/code>-Datei die Quarkus-Version, da wir diese sp\u00e4ter an zwei Stellen ben\u00f6tigen werden (dem Import der \u201eBill of Materials\u201c und der Integration des Quarkus-Maven-Plugins). An welcher Stelle du die Quarkus-Version einf\u00fcgst, ist technisch egal \u2013 der \u00dcbersichtlichkeit halber f\u00fcge ich die Version vor der PMD-Version ein:<\/p>\n\n\n

    <properties<\/span>><\/span>\n    . . .\n    <quarkus.platform.version<\/span>><\/span>3.36.2<\/quarkus.platform.version<\/span>><\/span>\n    <pmd.version<\/span>><\/span>7.25.0<\/pmd.version<\/span>><\/span>\n    . . .\n<\/properties<\/span>><\/span><\/code><\/span>Code-Sprache:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
    \n
    <\/path><\/svg><\/div>
    <\/div>
    Jetzt kommt es darauf an, wo du startest:

    Wenn dein Startpunkt der Code ist, den wir in den vorherigen Teilen des Tutorials gemeinsam entwickelt haben, dann hast du noch keinen <dependencyManagement><\/code>-Block in der pom.xml<\/code>.

    Wenn du das Projekt hingegen aus meinem GitHub-Repository geklont hast, dann findest du solch einen Block, der die Versionsnummern aller Dependencies zentral verwaltet.

    Warum dieser Unterschied? Im Tutorial habe ich die Versionsnummern immer direkt bei den Dependencies angegeben, da ich das Tutorial auf diese Weise f\u00fcr verst\u00e4ndlicher hielt, als wenn du f\u00fcr jede Abh\u00e4ngigkeit einen Eintrag in den <dependencies><\/code>-Block des jeweiligen Moduls und einen weiteren Eintrag in den <dependencyManagement><\/code>-Block des \u00fcbergeordneten POMs h\u00e4ttest einf\u00fcgen m\u00fcssen.<\/p><\/div><\/div>\n<\/div>\n\n\n\n
    Falls du schon einen <dependencyManagement><\/code>-Block hast, dann ersetze ihn durch den folgenden Block. Und wenn du noch keinen hast, dann f\u00fcge den folgenden Block einfach hinzu \u2013 z. B. vor den bestehenden <dependencies><\/code>-Block:<\/p>\n\n\n
    <dependencyManagement<\/span>><\/span>\n    <dependencies<\/span>><\/span>\n        <!-- Quarkus \"Bill of Materials\" --><\/span>\n        <dependency<\/span>><\/span>\n            <groupId<\/span>><\/span>io.quarkus.platform<\/groupId<\/span>><\/span>\n            <artifactId<\/span>><\/span>quarkus-bom<\/artifactId<\/span>><\/span>\n            <version<\/span>><\/span>${quarkus.platform.version}<\/version<\/span>><\/span>\n            <type<\/span>><\/span>pom<\/type<\/span>><\/span>\n            <scope<\/span>><\/span>import<\/scope<\/span>><\/span>\n        <\/dependency<\/span>><\/span>\n\n        <dependency<\/span>><\/span>\n            <groupId<\/span>><\/span>com.tngtech.archunit<\/groupId<\/span>><\/span>\n            <artifactId<\/span>><\/span>archunit<\/artifactId<\/span>><\/span>\n            <version<\/span>><\/span>1.4.2<\/version<\/span>><\/span>\n        <\/dependency<\/span>><\/span>\n    <\/dependencies<\/span>><\/span>\n<\/dependencyManagement<\/span>><\/span><\/code><\/span>Code-Sprache:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
    Der erste Eintrag f\u00fcgt dem Projekt die oben erw\u00e4hnte Bill of Materials (BoM) hinzu, und der zweite definiert die ArchUnit-Version, welche in der Quarkus-BoM nicht definiert ist.<\/p>\n\n\n\n
    Im <dependencies><\/code>-Block k\u00f6nnen wir jetzt bei JUnit und Mockito die Versionsnummern entfernen, da diese Versionen in der Bill of Materials bereits definiert sind. Die Versionen von Lombok und AssertJ hingegen sind in der BoM nicht definiert, wir m\u00fcssen sie also explizit angeben.<\/p>\n\n\n\n
    Hier siehst du den vollst\u00e4ndigen <dependencies><\/code>-Block:<\/p>\n\n\n
    <dependencies<\/span>><\/span>\n    <!-- Provided scope (shared by all modules) --><\/span>\n    <dependency<\/span>><\/span>\n        <groupId<\/span>><\/span>org.projectlombok<\/groupId<\/span>><\/span>\n        <artifactId<\/span>><\/span>lombok<\/artifactId<\/span>><\/span>\n        <version<\/span>><\/span>1.18.46<\/version<\/span>><\/span>\n        <scope<\/span>><\/span>provided<\/scope<\/span>><\/span>\n    <\/dependency<\/span>><\/span>\n\n    <!-- Test scope (shared by all modules) --><\/span>\n    <dependency<\/span>><\/span>\n        <groupId<\/span>><\/span>org.junit.jupiter<\/groupId<\/span>><\/span>\n        <artifactId<\/span>><\/span>junit-jupiter<\/artifactId<\/span>><\/span>\n        <!-- JUnit version comes from Quarkus BoM --><\/span>\n        <scope<\/span>><\/span>test<\/scope<\/span>><\/span>\n    <\/dependency<\/span>><\/span>\n    <dependency<\/span>><\/span>\n        <groupId<\/span>><\/span>org.assertj<\/groupId<\/span>><\/span>\n        <artifactId<\/span>><\/span>assertj-core<\/artifactId<\/span>><\/span>\n        <version<\/span>><\/span>3.27.7<\/version<\/span>><\/span>\n        <scope<\/span>><\/span>test<\/scope<\/span>><\/span>\n    <\/dependency<\/span>><\/span>\n    <dependency<\/span>><\/span>\n        <groupId<\/span>><\/span>org.mockito<\/groupId<\/span>><\/span>\n        <artifactId<\/span>><\/span>mockito-core<\/artifactId<\/span>><\/span>\n        <!-- Mockito version comes from Quarkus BoM --><\/span>\n        <scope<\/span>><\/span>test<\/scope<\/span>><\/span>\n    <\/dependency<\/span>><\/span>\n<\/dependencies<\/span>><\/span><\/code><\/span>Code-Sprache:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
    Anpassung der adapter\/pom.xml<\/h3>\n\n\n\n
    Als n\u00e4chstes \u00e4ndern wir die Dependencies in der adapter\/pom.xml<\/code>. Wir haben dort bisher z. B. Dependencies zu Jakarta RESTful Web Services, Jakarta Persistence, RESTEasy, Hibernate und dem MySQL-Treiber angegeben. Wir ersetzen jetzt all diese Libraries durch die entsprechenden Quarkus Extensions (ich zeige dir gleich, wie die pom.xml<\/code> danach aussehen wird).<\/p>\n\n\n\n
    \n
    <\/path><\/svg><\/div>
    <\/div>
    Quarkus Extensions<\/a> sind kleine Wrapper um die eigentlichen Libraries, die diese um einige Informationen anreichern, die es erm\u00f6glichen, dass eine Quarkus-Anwendung mit GraalVM<\/a> in eine native Anwendung<\/a> kompiliert werden kann.<\/p><\/div><\/div>\n<\/div>\n\n\n\n
    Wir f\u00fcgen auch einige Extensions hinzu, die wir aktuell noch nicht brauchen, aber im weiteren Zuge der Migration brauchen werden:<\/p>\n\n\n\n
    Als n\u00e4chstes m\u00fcssen wir die eben genannte \u201eBill of Materials\u201c integrieren. Eine \u201eBill of Materials\u201c ist im Grunde eine Liste, die definiert, welche Versionen von welchen Libraries zusammenpassen. In der Bill of Materials von Quarkus, Version 3.36.2<\/a> steht z. B. dass Hibernate in der Version 7.3.7.Final verwendet werden soll und JUnit in der Version 6.0.3.<\/p>\n\n\n\n