Maven-Archetypes: Auferstanden wie der Phönix aus der Asche

Wer aktuell Backend-Software entwickelt, kommt am Thema Microservices nicht vorbei. Die Vorteile von Microservices liegen auf der Hand:

• individuelle Skalierung
• unabhängige kleine Services mit überschaubaren Funktionsumfang
• die Möglichkeit, unterschiedliche Programmiersprachen und Technologien innerhalb eines Projektes zu nutzen

Es gibt noch diverse weitere Vorteile, die aber schon vielfach hinlänglich im Netz dokumentiert sind. Dieser Beitrag widmet sich der Wartbarkeit von Microservices.

Software-Projekte werden immer komplexer. Viele unterschiedliche Programmiersprachen und Technologien werden verwendet. Das sorgt dafür, dass der Code schwieriger zu warten ist. Entwickler sind nicht nur mit heterogenen Softwarearchitekturen konfrontiert. Sie müssen sich auch mit allen verwendeten Technologien und Programmiersprachen auskennen. Das stellt hohe Ansprüche an das Skillset (Vergleiche Beitrag „Die Legende vom Fullstack-Developer“) und wird besonders in Teams mit hoher Fluktuation problematisch.

Das Prinzip zur Nutzung unterschiedlicher Technologien in einzelnen Microservices kollidiert mit dem SCRUM Entwicklungs-Prozess. Dem Scrum-Prinzip folgend versucht man, ein möglichst homogenes Team zu bilden, um Risiken für einen eventuellen Ausfall eines Teammitglieds zu minimieren. Diverse eingesetzte Technologien und Programmiersprachen erhöhen das Risiko — Stichwort Skill-Inseln.

Diversität einfach vermeiden

Nun wird ein schon lange existierendes Toolkit plötzlich wieder aktuell: Maven-Archetypes. Meines Erachtens nach ist es heute sogar sinnvoller, diese Technik für Microservices zu nutzen, als zu den Zeiten ihrer Entstehung. Denn bei aktuellen Software-Projekten werden viel mehr Services erstellt. Die Idee dahinter ist so einfach wie genial.

Man erstellt ein Template, in dem der architektonische Aufbau der Microservices genau definiert wird. Diese Schablone wird bei allen neuen Microservices verwendet. Das sorgt für einheitliche Strukturen, was die Wartbarkeit deutlich erleichtert. Zudem spart es jede Menge Zeit, denn man muss sich nicht immer wieder neue Gedanken um die Grundarchitektur machen.

Maven-Archetypen einfach entwickeln

Einen Maven-Archetype zu schreiben ist keine Raketenwissenschaft. Das Maven-Archetype Plugin bietet Tools, um aus einer bestehenden Projektstruktur einen passenden Maven-Archetype zu generieren. Der zentrale Punkt eines Maven-Archetype ist die archetype-metadata.xml-Datei, die den Aufbau des Projektes beschreibt. Hier kann man die verschiedenen Module definieren.

Vorsicht! Aus meiner Sicht gibt es auf der Apache-Maven-Archetype-Seite einen Dokumentationsfehler. Dort existiert noch eine veraltete Archetype-Descriptor-Reference, die der aktuellen Reference sehr ähnelt. Aber das Root-Element des XMLs heißt nicht mehr „archetype-descriptor“, sondern nur noch „archetype“. Nachzulesen im Guide https://maven.apache.org/guides/mini/guide-creating-archetypes.html.

Beispielhafter Microservice-Archetype auf Basis von Spring Boot

Der Aufbau dieses Archetypes sieht eine strikte Trennung der typischen Backend-Layer vor:

• Schnittstelle zum Frontend (API)
• Webservice-Layer (die Implementierung der Controller Schicht).
• Service-Layer als Bindeglied zwischen Controller- und Persistenz-Schicht, das den Großteil der Businesslogik beinhalten sollte (service)
• Persistence-Layer (domain), der die Datenbank-Zugriffe enthält.

Ich empfehle, dieses Layer-System strikt einzuhalten. Das gilt für den Zugriff (Controller → Service → Persistence) und dafür, eigene Models für jeden Layer zu definieren, um Seiteneffekte bei der Programmierung (z.B. ungewollte Schnittstellenänderungen für Clients) zu vermeiden. Mit diesem Modell ist man sehr flexibel, weil man das Persistence-Model variieren kann, ohne gleich auch die API ändern zu müssen. Ich empfehle, gerade jungen Entwicklern so eine Struktur vorzugeben. Das vermeidet typische Fehler und erleichtert bei möglichen Problemen das spätere Refactoring.

Innerhalb dieser Software-Module (einzelne Layer) können bereits die fertigen pom-Dateien mit den gegenseitigen Abhängigkeiten definiert werden. Auch vorgefertigte Klassen sind möglich, sodass nach dem Generieren des Projektes aus dem Archetype bereits eine voll funktionsfähige Anwendung definiert ist, inklusive Persistence mit Beispiel-Implementierung.

Gerade diese Beispiel-Implementierung ist für wenig erfahrene Entwickler hilfreich. Denn sie zeigt, wo in welchem Layer welche Funktionen implementiert werden sollen, um Architekturbrüche zu vermeiden und somit die Wartbarkeit der Software zu senken.

Schreiben ist einfach, veröffentlichen leider nicht

Für das Veröffentlichen und Teilen von Maven-Archetypes sind sogenannte archetype catalogs vorgesehen. In diesen kann man seinen eigenen Archetype-Katalog definieren und den Entwicklern zur Verfügung stellen. Das gestaltet sich allerdings recht kompliziert. Meine Empfehlung hierfür ist, die Katalogdatei am Root des Artefakt-Repositories abzulegen.

Ich habe versucht, den Archetype in einem gesicherten Artefakt-Repository zur Verfügung zu stellen. Dabei habe ich trotz mehrfacher Versuche keine passende Maven-Konfiguration erstellen können, mit der ich den Archetype direkt aus dem Repository nutzen konnte. Auch die Tipps von der offiziellen Apache Maven-Seite halfen nicht.

Meine dringende Empfehlung ist daher, die Archetypes in einem ungesicherten Repository abzulegen, falls das mit den Unternehmens-richtlinien vereinbar ist.

Maven-Archetypes eignen sich nicht nur für Java-Projekte

Das Template-Toolkit ist aus meiner Sicht so aktuell und sinnvoll wie nie zuvor. Maven-Archetypes sind gerade am Anfang eines Projektes sehr hilfreich und verhindern größere Refactorings. Die Vorteile gelten natürlich nicht nur bei Java-Projekten. Auch für andere Projekte und Programmiersprachen. Das reduziert auch hier die Diversität, zum Beispiel von Frontend-Modulen, und offeriert gleichzeitig einen Leitfaden für unerfahrene Entwickler.