super Veranschaulichung, vielen Dank dafür! Als es ums Thema Schichten-Trennung ging, fiel mir direkt ArchUnit ein -- umso besser, dass es direkt integriert ist. Inwieweit sich der "magische Ansatz" von Spring hier anbietet oder ein eigener Ansatz, wird sich zeigen. Meistens liegt die Wahrheit ja irgendwo in der Mitte ;-)
Hallo Thomas, danke für diese Einführung. So sehr ich auch die Intention von Spring Modulith begrüße, bin ich doch irgendwie sehr am zweifeln, ob dieser Ansatz weit genug greift. Meine Hauptkritik ist, dass die Modularisierung ausschließlich "gedanklich" vorhanden ist. Es werden keinerlei höherwertige Modulkonzepte verwendet, die schon zur Entwicklungszeit greifen und zum Teil deutlich strenger und mächtiger sind. Es werden keine Java Modules verwendet. Außerdem haben wir keine getrennten Maven-Module und keine getrennten Repositories. Für die Entwickler ist es also weiterhin ein großer Code-Monolith, wo sich alle gleichzeitig mit ihren Änderungen, Abhängigkeiten und Commits in die Quere kommen. Das Konzept klingt auch nicht so, als ob es gut geeignet ist, wenn man nachträglich einen Modulithen zu echten Microservices umbauen möchte. Das geht los mit der Unterscheidung zwischen interner und externer Events - wobei das immerhin schon gut ist, dass beides möglich ist. Ich vermisse aber einen allgemeinen Ansatz von Commands und Queries, wenn ich die APIs anderer Module aufrufen will. Und dann ist da noch das große Problem des gemeinsamen Applikationskontextes. Connection Pools, Caches, Transaktionen - das alles ist vermutlich modulübergreifend und kann natürlich entsprechende Seiteneffekte bewusst oder unbewusst hervorrufen. Insofern stellt sich mir die Frage nach dem wirklich Ziel von Spring Modulith. Ja, es unterstützt sicherlich die saubere Strukturierung einer Spring-Boot-Anwendung, aber aus meiner Sicht geht es längst nicht weit genug, um als Vorstufe echter Microservices zu dienen - in dem Sinne, dass man später jederzeit einzelne oder mehrere Module in autarke Services ausgliedern kann.
Hallo Marcom, danke für deine Kritik an Spring Modulith und die Diskussionspunkte. Ich frage mich auch, wo Java- oder Maven Module vielleicht besser passen. OSGi hätte noch eine Alternative sein können, die viele Probleme ganz gut gelöst hätte. Leider hat sich OSGi aber nicht so verbreitet. Das mit dem späteren Ausgliedern ist meiner Meinung nach mehr ein Argument als eine Eigenschaft.
@@thomas-bayer Hallo Thomas, ich habe vor ca. 3 Jahren mal an einem Spring-Boot-Projekt teilgenommen, wo wir für jeden Bounded Context zwei eigene Maven-Module erstellt haben: Eines für die Implementierung und eines für die öffentliche API. Jedes dieser Module hatte auch sein eigenes git-Repo. Java Modules waren damals nicht im Fokus, kann also nicht sagen, ob man den Ansatz sinnvoll nutzen könnte. Was wir aber gemacht haben: Jeder Bounded Context hatte seine eigene SubApplication mit eigenem Spring Context. Die Module wurden dann durch eine Spring Boot Application zusammengefasst. Kommunikation fand nur über die APIs statt, wobei die APIs letztlich aus Commands, Queries und Events bestanden. Ich denke Du verstehst, wohin die Reise da geht. Ist natürlich ein viel komplexeres Setup, aber gerade hier würde einem ein entsprechen vorgefertigtes "Modulith-Framework" viel Arbeit abnehmen könnnen.
@@marcom. danke für die Beschreibung. Ich hoffe, dass Spring Modulith dazu beiträgt, dass mehr in Modularisierung investiert wird. Die Techniken dafür sind wie du beschreibst alle schon da. Die Maven-Module, SOLID-Prinzipien, Frameworks, ...
Danke für das Feedback. Grundsätzlich ist zu sagen, dass Spring Modulith keine Entweder-Oder-Alternative zu anderen Modulansätzen ist. Zum Einen ist das Featurespektrum von Spring Modulith *komplett* auf Applikationsentwickler zugeschnitten. Zum Anderen "fehlen" den von dir genannten Alternativen Features wie die Testintegration, die Dokumentation usw. völlig, und haben einen deutlich technischeren Fokus (JPMS: 1:1 Beziehung zwischen Modul & JAR usw.). Wichtig ist eigentlich zu erkennen, dass es eine Art "Werkzeugraum" gibt, in dem jedes Werkzeug unterschiedliche Tradeoffs eingeht und sich die Werkzeuge auch kombinieren lassen. Wenn man das Abhängigkeitsmanagement eher über Buildmodule realisieren möchte: bitte gern. Dann kann man immer noch die Dokumentations- und Integrationstestfeatures von Spring Modulith nutzen. Etwas herausgezoomt ist uns wichtig, den Blick für dieses Thema zu schaffen: wie bilde ich eine fachliche Architektur in einer Applikation ab. Der potentielle Umbau in ein später verteiltes System ist durchaus ein Thema für uns. Der gesamte Bereich der Unterstützung für Event-basierte Kommunikation bereitet genau das vor, weil man dadurch die Transaktionsklammern bereits auf einzelne Module begrenzt. Ist das erstmal in der Applikation etabliert, ist es recht einfach, ein Modul in eine separate App zu schieben und die Events z. B. über einen Kafka in die andere Applikation zu tragen. Das funktioniert in den Produktionsdeployments die wir aktuell sehen ziemlich gut. Ich weiß von Projekten, die nicht Spring Modulith verwenden, aber für jedes logische Modul einen separaten ApplicationContext starten. Das erfordert deutlich mehr technische Koordination und verbraucht deutlich mehr Ressourcen (EntityManager und Servletcontainer pro Kontext usw.) Ich sage nicht, dass das falsch ist. Es ist nur wieder ein anderer Tradeoff. Gut möglich, dass wir das irgendwann als advanced Feature auch mal anvisieren.
Man trennt in Interface und Implementierung, um Komponenten zu bilden. Andere Module können das Interface kennen, die Implementierung ist aber verborgen, d.h. ein anderes Modul hat nur eine Abhängigkeit auf die Schnittstelle. Das trägt zur Gliederung und Flexibilität der Anwendung bei. Die Trennung benutzt man dann, wenn man abstrahieren möchte. Die Abstraktion hat aber auch ihren Preis. Es kann daher sinnvoll sein, in Interface und Implementierung zu trennen oder auf das Interface zu verzichten.
![Eminem - Somebody Save Me (feat. Jelly Roll) [Official Music Video]](http://i.ytimg.com/vi/Vwa0HenQMi4/mqdefault.jpg)
super video!
super Veranschaulichung, vielen Dank dafür! Als es ums Thema Schichten-Trennung ging, fiel mir direkt ArchUnit ein -- umso besser, dass es direkt integriert ist. Inwieweit sich der "magische Ansatz" von Spring hier anbietet oder ein eigener Ansatz, wird sich zeigen. Meistens liegt die Wahrheit ja irgendwo in der Mitte ;-)
Danke für deinen Kommentar.
Thank you so much, I´m sorry for my English, I´m from Bolivia and speak Spanish.. I´m happy fpr my with your video explain, grettings.
Thanks for the comment. Hope the subtitles weren't to bad.
Hallo Thomas,
danke für diese Einführung. So sehr ich auch die Intention von Spring Modulith begrüße, bin ich doch irgendwie sehr am zweifeln, ob dieser Ansatz weit genug greift.
Meine Hauptkritik ist, dass die Modularisierung ausschließlich "gedanklich" vorhanden ist. Es werden keinerlei höherwertige Modulkonzepte verwendet, die schon zur Entwicklungszeit greifen und zum Teil deutlich strenger und mächtiger sind. Es werden keine Java Modules verwendet. Außerdem haben wir keine getrennten Maven-Module und keine getrennten Repositories. Für die Entwickler ist es also weiterhin ein großer Code-Monolith, wo sich alle gleichzeitig mit ihren Änderungen, Abhängigkeiten und Commits in die Quere kommen.
Das Konzept klingt auch nicht so, als ob es gut geeignet ist, wenn man nachträglich einen Modulithen zu echten Microservices umbauen möchte. Das geht los mit der Unterscheidung zwischen interner und externer Events - wobei das immerhin schon gut ist, dass beides möglich ist. Ich vermisse aber einen allgemeinen Ansatz von Commands und Queries, wenn ich die APIs anderer Module aufrufen will. Und dann ist da noch das große Problem des gemeinsamen Applikationskontextes. Connection Pools, Caches, Transaktionen - das alles ist vermutlich modulübergreifend und kann natürlich entsprechende Seiteneffekte bewusst oder unbewusst hervorrufen.
Insofern stellt sich mir die Frage nach dem wirklich Ziel von Spring Modulith. Ja, es unterstützt sicherlich die saubere Strukturierung einer Spring-Boot-Anwendung, aber aus meiner Sicht geht es längst nicht weit genug, um als Vorstufe echter Microservices zu dienen - in dem Sinne, dass man später jederzeit einzelne oder mehrere Module in autarke Services ausgliedern kann.
Hallo Marcom, danke für deine Kritik an Spring Modulith und die Diskussionspunkte. Ich frage mich auch, wo Java- oder Maven Module vielleicht besser passen. OSGi hätte noch eine Alternative sein können, die viele Probleme ganz gut gelöst hätte. Leider hat sich OSGi aber nicht so verbreitet. Das mit dem späteren Ausgliedern ist meiner Meinung nach mehr ein Argument als eine Eigenschaft.
@@thomas-bayer Hallo Thomas, ich habe vor ca. 3 Jahren mal an einem Spring-Boot-Projekt teilgenommen, wo wir für jeden Bounded Context zwei eigene Maven-Module erstellt haben: Eines für die Implementierung und eines für die öffentliche API. Jedes dieser Module hatte auch sein eigenes git-Repo. Java Modules waren damals nicht im Fokus, kann also nicht sagen, ob man den Ansatz sinnvoll nutzen könnte. Was wir aber gemacht haben: Jeder Bounded Context hatte seine eigene SubApplication mit eigenem Spring Context. Die Module wurden dann durch eine Spring Boot Application zusammengefasst. Kommunikation fand nur über die APIs statt, wobei die APIs letztlich aus Commands, Queries und Events bestanden. Ich denke Du verstehst, wohin die Reise da geht. Ist natürlich ein viel komplexeres Setup, aber gerade hier würde einem ein entsprechen vorgefertigtes "Modulith-Framework" viel Arbeit abnehmen könnnen.
@@marcom. danke für die Beschreibung. Ich hoffe, dass Spring Modulith dazu beiträgt, dass mehr in Modularisierung investiert wird. Die Techniken dafür sind wie du beschreibst alle schon da. Die Maven-Module, SOLID-Prinzipien, Frameworks, ...
Danke für das Feedback. Grundsätzlich ist zu sagen, dass Spring Modulith keine Entweder-Oder-Alternative zu anderen Modulansätzen ist. Zum Einen ist das Featurespektrum von Spring Modulith *komplett* auf Applikationsentwickler zugeschnitten. Zum Anderen "fehlen" den von dir genannten Alternativen Features wie die Testintegration, die Dokumentation usw. völlig, und haben einen deutlich technischeren Fokus (JPMS: 1:1 Beziehung zwischen Modul & JAR usw.).
Wichtig ist eigentlich zu erkennen, dass es eine Art "Werkzeugraum" gibt, in dem jedes Werkzeug unterschiedliche Tradeoffs eingeht und sich die Werkzeuge auch kombinieren lassen. Wenn man das Abhängigkeitsmanagement eher über Buildmodule realisieren möchte: bitte gern. Dann kann man immer noch die Dokumentations- und Integrationstestfeatures von Spring Modulith nutzen. Etwas herausgezoomt ist uns wichtig, den Blick für dieses Thema zu schaffen: wie bilde ich eine fachliche Architektur in einer Applikation ab.
Der potentielle Umbau in ein später verteiltes System ist durchaus ein Thema für uns. Der gesamte Bereich der Unterstützung für Event-basierte Kommunikation bereitet genau das vor, weil man dadurch die Transaktionsklammern bereits auf einzelne Module begrenzt. Ist das erstmal in der Applikation etabliert, ist es recht einfach, ein Modul in eine separate App zu schieben und die Events z. B. über einen Kafka in die andere Applikation zu tragen. Das funktioniert in den Produktionsdeployments die wir aktuell sehen ziemlich gut.
Ich weiß von Projekten, die nicht Spring Modulith verwenden, aber für jedes logische Modul einen separaten ApplicationContext starten. Das erfordert deutlich mehr technische Koordination und verbraucht deutlich mehr Ressourcen (EntityManager und Servletcontainer pro Kontext usw.) Ich sage nicht, dass das falsch ist. Es ist nur wieder ein anderer Tradeoff. Gut möglich, dass wir das irgendwann als advanced Feature auch mal anvisieren.
Wieso trennt man in ein Interface und eine Implementierung und macht nicht einfach eine normale Java Class als Service?
Man trennt in Interface und Implementierung, um Komponenten zu bilden. Andere Module können das Interface kennen, die Implementierung ist aber verborgen, d.h. ein anderes Modul hat nur eine Abhängigkeit auf die Schnittstelle. Das trägt zur Gliederung und Flexibilität der Anwendung bei. Die Trennung benutzt man dann, wenn man abstrahieren möchte. Die Abstraktion hat aber auch ihren Preis. Es kann daher sinnvoll sein, in Interface und Implementierung zu trennen oder auf das Interface zu verzichten.
Eure Fruitshop API Funktioniert nicht :) Wann läuft die wieder ?
Danke für den Hinweis. Die API sollte verfügbar sein. Gab es eine Fehlermeldung oder ein Timeout?
It was a great video, but it could have been better if I understood the German language.
Thanks for your feedback. Hope the automatic translation works good enough.
@@thomas-bayer I can understand better with the draws, thanks for that.