Agile Coding mit Java, Kotlin, Spring und Microservices

Unser Java-System ist jetzt mit Spring Boot Version 3 im produktiven Einsatz! Hier teile ich meinen Erfahrungsbericht, da sich Systeme in der echten Welt häufig von Demos oder Tutorials unterscheiden. Highlights Spring Boot 3 Warum auf Spring Boot 3 und damit auf die Version 6 des Spring Frameworks updaten? Spring 6 ist auf die aktuelle Java LTS Version 17 aktualisiert. Damit modernisiert Spring sich in erster Linie selbst, wovon wir indirekt profitieren. Native Images mit GraalVM werden offiziell supported. Das ermöglicht unserer Spring Anwendung den blitzschnellen Start als Docker Container, siehe graalvm.html . Viele direkt oder indirekt verwendete 3rd Party Bibliotheken sind auf neue Versionen aktualisiert. Wir bekommen damit diverse Fixes für Sicherheitslücken. Planung des Spring Boot 3 Updates Der Spring Boot 3.0 Migration Guide enthält im Wesentlichen diese Schritte: Update auf Spring Boot 2.7 Update auf Java 17 Update auf Spring Boot 3 Dependencies anpassen Code anpassen Unser

REST-APIs können als OpenAPI Spezifikation menschen- und maschinenlesbar beschrieben werden. Die maschinenlesbare OpenAPI Spezifikation (vormals bekannt als Swagger Spezifikation) dient Code-Generatoren als Vorlage zum Generieren von Client- oder Server-Code in viele verschiedenen Programmiersprachen. Neben den Basics zeige ich euch hier, wie man den Code-Generator mit Maven verwendet, um API Implementierung und Spezifikation immer synchron zu halten. API first & Code Generatoren Beim API first Konzept geht es darum, dass man von Anfang an, die API im Scope der Entwicklung hat. Die API wird vor der Implementierung definiert und kann auch schon mit anderen Teams ausgetauscht werden, welche den Service über die API nutzen. Wird die API als OpenAPI Spezifikation im json oder yaml Format definiert, können mehrere Teams den Client-Code zeitgleich mit der Service-Implementierung entwickeln. Als Unterstützung für den API first Ansatz gibt es Code Generatoren, die für euch ein Client SDK

Wie schaffen wir es komplexe monolithische Systeme so zu zerlegen, dass die einzelnen Sub-Systeme leicht und unabhängig voneinander entwickelt werden können? In diesem Erfahrungsbericht zeige ich, wie wir ein Shopping-Portal in Microservices und Self-Contained-Systems (SCS) zerlegt haben. Der Artikel ist ein Erfahrungsbericht und beschreibt nur unseren Weg. Es gibt hier sicherlich viele alternative Lösungen. Mit Sicherheit gibt es auch rein Microservice-basierte Architekturen, welche die hier gezeigten Probleme lösen könnten. Video-Präsentation zum Artikel Ausgangssituation: der Monolith Monolithen werden in der IT häufig als einzelnes System beschrieben, das alle Funktion beinhaltet, siehe  https://www.itwissen.info/Monolithische-Software-Architektur.html . Nach dieser Definition hätten wir eigentlich kein Problem, da ich hier ein Content-basiertes Shopping-System betrachte, welches diverse Backend-Systeme über REST-APIs aufruft, die Teile der Funktionalität bereitstellen, z.B. einen