Interview mit Lars Röwekamp

„Java EE und Microservices – rein technologisch spricht nichts gegen dieses Duo“

Hartmut Schlosser

Java EE soll modernisiert und für Cloud-basierte Microservices-Anwendungen fit gemacht werden. Wir haben uns mit W-JAX-Speaker Lars Röwekamp darüber unterhalten, wie Microservice-Architekturen jetzt schon mit Java-EE-Bordmitteln realisiert werden können, und welche Rolle das Konzept des Domain-driven Design dabei spielt.

JAXenter: Java EE und Microservices – dieses Thema behandelst du auf der W-JAX. Zu welchem Grad geht das denn jetzt schon?

Lars Röwekamp: Auch wenn es in den Medien gerne anders propagiert wird, spricht – rein technologisch gesehen – erst einmal nichts gegen dieses Duo. Der Enterprise-Java-Standard bringt alles an APIs mit, was es zum Entwickeln von Microservices-basierten Systemen bedarf. Etwas problematischer wird es, wenn wir einen Blick auf die Laufzeitumgebung werfen. Ein Application Server pro Microservice scheint ein wenig „oversized“. Mehrere Services innerhalb eines Application Servers, z.B. in Form von unterschiedlichen WARs, wiedersprechen dagegen dem Prinzip der vollständigen Unabhängigkeit.

Ein guter Kompromiss scheinen hier die Ansätze von Wildfly Swarm, KumuluzEE, Payara Micro Glassfish oder TomEE Shades zu sein. Allen gemein ist, dass sie die für den jeweiligen Microservices notwendigen Serverkomponenten (und nur genau diese) inkl. Bootstraping mit dem Service bundeln, um diesen dann als eigenständiges JAR zur Verfügung zu stellen. Natürlich ist dieser Ansatz nicht neu. Dropwizard und Spring Boot haben es bereits erfolgreich vorgemacht, eben nur außerhalb des Standards.

JAXenter: Die Debatte um Java EE läuft ja gerade heiß. Auf der JavaOne hat Oracle gerade seine Vision von Java EE für die Cloud vorgestellt, und dann gibt es noch die Initiative MicroProfile.io. In welche Richtung sollte sich Java EE deiner Meinung nach bewegen?

Es könnte durchaus Sinn ergeben, den aktuell stark von Oracle geprägten JCP auf mehrere Schultern zu verteilen.

Lars Röwekamp: Das ist eine gute und gleichzeitig nicht ganz einfache Frage. Die Initiative MicroProfile.io hat gezeigt, dass es nach wie vor einen Bedarf in der Community nach Standardisierung bzw. nach einheitlichen Lösungen gibt. Denn nach den Erfahrungen der Vergangenheit möchte man sich nur ungern von einzelnen Herstellen abhängig machen. Gleichzeitig möchte man aber auch, dass neue Trends und Innovationen in endlicher Zeit vorangetrieben werden.

Was bedeutet das nun für die Java-EE-Spezifikation? Es könnte durchaus Sinn ergeben, den aktuell stark von Oracle geprägten JCP auf mehrere Schultern zu verteilen und dabei darauf zu achten, dass sich die einzelnen Parteien verpflichten, für die verschiedenen JSRs einen kontinuierlichen Fortschritt zuzusichern. Dabei muss man meiner Ansicht nach gar nicht unbedingt immer alles gleich standardisieren, denn dies birgt die Gefahr, zu unflexibel zu werden. Es könnte z.B. eine Art Evolutionsphase für die einzelnen JSRs geben, in deren Rahmen die angedachten Ideen für einen gewissen Zeitrahmen von der Community auf Praxistauglichkeit getestet werden. Dies hätte den Charme, dass es sehr schnell standardähnliche Lösungen geben würde, die dann am Ende nach einigen, sich aus dem Feedback der Community ergebenen Adaptionen in einen allgemeinen Standard münden. Dass dies sehr gut funktionieren kann, hat uns ja bereits die Kombination Hibernate und JPA gezeigt.

JAXenter: Bei der Umsetzung von Microservice-Architekturen wird ja immer wieder auf Eric Evans‘ Buch „Domain-driven Design“ von 2003 verwiesen. Weshalb erlebt DDD momentan gerade eine Art Revival?

Lars Röwekamp: In den ersten Jahren wurde DDD lediglich von einer kleinen Gruppe „Interessierter“ adaptiert, die es bereits damals verstanden haben, dass es bei der Entwicklung von Software eher um die korrekte Umsetzung von Fachlichkeit als um technologische Aspekte geht. Ein stets in sich konsistentes Domänen-Modell garantiert, dass es nicht zu unerwarteten Seiteneffekten kommen kann.

Durch die, in der Vergangenheit meist strikte Trennung von Fach- und Entwicklungsabteilung, war es bis dato nicht ganz trivial für DDD, seine Trümpfe voll auszuspielen. Mit der Einführung von agilen und cross-functional orientierten Teams hat sich die Ausgangssituation vor wenigen Jahren schlagartig geändert. Fachabteilung und Entwicklung rücken mehr und mehr zusammen. Der Entwickler mutiert – im positiven Sinne – vom Technologielöser zum Fachentwickler.

Nur wenn ich es schaffe, Microservices fachlich sinnvoll zu schneiden, bekomme ich die gewünschte lose Kopplung.

Einen weiteren, wenn nicht sogar den entscheidenden Kick hat DDD durch den Siegeszug der Microservices erhalten. Denn nur, wenn ich es schaffe, Microservices fachlich sinnvoll und möglichst unabhängig voneinander zu schneiden – in DDD spricht man hier von einem „Bounded Context“ –, bekomme ich die gewünschte lose Kopplung mit all seinen Vorteilen. Gelingt mir dies nicht, dann kommt an Ende ein „verteilter Monolith“ heraus, also quasi das Worste Case Scenario der Software-Entwicklung.

JAXenter: Die Prinzipien für DDD sind meist grundsätzlich bekannt – allein die Umsetzung in der Praxis ist alles andere als trivial. Auf welche typischen Probleme bist du in Projekten bei der Umsetzung von DDD gestoßen?

Lars Röwekamp: Das größte Problem ist fast immer das Finden einer gemeinsamen, fachlich motivierten Sprache zwischen Entwicklern und Fachexperten, in DDD „Ubiquitous Language“ genannt. Dies klingt zwar trivial, ist aber für den Erfolg eines Projektes essentiell. Denn erst, wenn ich mich auf diese eine gemeinsame Sprache (pro Fachdomäne) geeinigt habe, kann ich auch sicher sein, dass alle Beteiligten in den Diskussionen das gleiche meinen.

Gelingt dies nicht, sind Missverständnisse und somit fachliche Fehler in der Software bzw. dem Domänen-Modell per Definition vorprogrammiert. Nehmen wir einmal das Beispiel „Arzt“. Aus Sicht eines Entwicklers ist ein Arzt ein Mensch, der andere Menschen in (s)einer Praxis behandelt und damit Geld verdient. Aus Sicht eines Fachexperten sind dies aber unter Umständen völlig verschiedene Dinge. Denn für den Fachexperten gibt es einen Behandler, einen Abrechner und einen Praxisbetreiber. Diese können ein und dieselbe Person sein, müssen es aber nicht. Unter Umständen sind es noch nicht einmal reale, sondern nur juristische Personen. Erst die Differenzierung in der Sprache und das damit verbundene Nutzen der Fachtermini stellt sicher, dass bei der Analyse der Fachlichkeit die Fachexperten und die Entwickler nicht aneinander vorbeireden. Dies wiederum ist die Grundvoraussetzung für korrekte Software.

JAXenter: Kannst du einen Praxis-Tipp geben, wie DDD erfolgreich realisiert werden kann?

Fachexperten und Entwickler müssen sich immer wieder an einen Tisch setzen.

Lars Röwekamp: Mein Pro-Tipp No. 1 heißt „üben, üben, üben“. Auch das klingt wieder trivial, ist aber nach unseren Erfahrungen der Schlüssel zum Erfolg. Wichtig dabei ist, dass sich Fachexperten und Entwickler immer wieder an einen Tisch setzen und über die umzusetzende Fachlichkeit und das aktuelle Domänen-Modell diskutieren. Dabei wird es immer wieder zu neuen Erkenntnissen und damit einhergehend zu einem beidseitig besseren Verständnis der fachlichen Domäne kommen. Natürlich können diese Erkenntnisse dazu führen, dass Änderungen am bestehenden Code notwendig sind. Aber das ist auch gut so. Denn um ehrlich zu sein, wäre es ja schon verwunderlich, wenn sich die Sicht auf die Fachlichkeit ändert, der zugehörige Code aber unverändert bleibt, denn dann hätte ich bereits vorher etwas falsch gemacht.

JAXenter: Vielen Dank für dieses Interview!

Lars RöwekampLars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.

 

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.