© Excellent backgrounds/Shutterstock.com
Java Magazin
Modulare Trennung von Infrastruktur und Fachlichkeit in Java EE

In kleinen Stücken


Schnell wachsende Webprojekte führen nicht selten zu einem Wartungsalbtraum. Ein Grund dafür ist die unscharfe Trennung zwischen Fachlichkeit und Architektur. Der Weg hin zu wartbaren, modular aufgebauten Applikationen ist lang und steinig. Aber er lohnt sich!

Video: Java EE Microservices mit WildFly Swarm, Payara Micro und Co.

Wir Entwickler arbeiten gerne mit sauber strukturierter Software, bei der Architektur und Fachlichkeit klar voneinander getrennt sind. Doch die Realität sieht meist anders aus: Viele Teammitglieder mit unterschiedlicher Expertise arbeiten gemeinsam an historisch wachsenden Webprojekten, deren Architektur sich im Laufe der Zeit um die fachlichen Anforderungen herum entwickelt hat. Es entstehen riesige Softwaremonolithen, deren Wartung und Erweiterung mit viel Aufwand verbunden sind. Spätestens, wenn eine Anwendung auf verschiedene, individuelle Kundenwünsche angepasst werden soll, muss ein Plan B her.

Eine Microservices-Architektur ist sicherlich der modernste Weg, jedoch ist der Komplettumbau von Monolithen nur selten finanzierbar. Hier können die Ergebnisse dieses Artikels als Zwischenschritt zur Microservices-Architektur gesehen werden. Bei der Entwicklung der Versicherungssuite Insurance out of the Box (IooB) stand die enowa AG vor ähnlichen Herausforderungen. Bei der Aufteilung eines bestehenden Java-EE-Projekts in fachliche Module konnten wir dabei bekannte Java-EE-Features aus der Perspektive der Modularisierung neu kennenlernen.

Vom Projekt zum Produkt

Modularität schafft Wiederverwendbarkeit – ein hohes Gut der Softwareentwicklung. Das betrifft nicht nur Methoden oder Klassen, auch ein ganzes Projekt rentiert sich oft erst dann, wenn ein daraus hervorgehendes Produkt auch weiteren Kunden angeboten werden kann. Dabei stellt sich jedoch rasch die Frage, wie die Aktivierung und Deaktivierung einzelner Features und deren Lizenzierung realisiert werden können. Oft ist es nötig, höchst individuelle Fachlichkeit eines Einzelkunden in das Projekt aufzunehmen, ohne dass dadurch die Ausführung für andere Kunden beeinflusst wird.

Ein gängiges Problem von Softwaremonolithen ist, dass die Kernapplikation zu viele Aufgaben aus den Bereichen Systemarchitektur, Fachlichkeit und Modulverwaltung übernimmt. Für ein solches Maven-Projekt ist in Listing 1 eine beispielhafte pom.xml aufgeführt. Das Artefakt core baut eine Abhängigkeit zu mehreren Featureartefakten auf. Was ist problematisch an diesem Vorgehen? Das Modul core ist durch den Ar...

Java Magazin
Modulare Trennung von Infrastruktur und Fachlichkeit in Java EE

In kleinen Stücken

Schnell wachsende Webprojekte führen nicht selten zu einem Wartungsalbtraum. Ein Grund dafür ist die unscharfe Trennung zwischen Fachlichkeit und Architektur. Der Weg hin zu wartbaren, modular aufgebauten Applikationen ist lang und steinig. Aber er lohnt sich!

Marvin Therolf, Richard Vogel


Schnell wachsende Webprojekte führen nicht selten zu einem Wartungsalbtraum. Ein Grund dafür ist die unscharfe Trennung zwischen Fachlichkeit und Architektur. Der Weg hin zu wartbaren, modular aufgebauten Applikationen ist lang und steinig. Aber er lohnt sich!

Video: Java EE Microservices mit WildFly Swarm, Payara Micro und Co.

Wir Entwickler arbeiten gerne mit sauber strukturierter Software, bei der Architektur und Fachlichkeit klar voneinander getrennt sind. Doch die Realität sieht meist anders aus: Viele Teammitglieder mit unterschiedlicher Expertise arbeiten gemeinsam an historisch wachsenden Webprojekten, deren Architektur sich im Laufe der Zeit um die fachlichen Anforderungen herum entwickelt hat. Es entstehen riesige Softwaremonolithen, deren Wartung und Erweiterung mit viel Aufwand verbunden sind. Spätestens, wenn eine Anwendung auf verschiedene, individuelle Kundenwünsche angepasst werden soll, muss ein Plan B her.

Eine Microservices-Architektur ist sicherlich der modernste Weg, jedoch ist der Komplettumbau von Monolithen nur selten finanzierbar. Hier können die Ergebnisse dieses Artikels als Zwischenschritt zur Microservices-Architektur gesehen werden. Bei der Entwicklung der Versicherungssuite Insurance out of the Box (IooB) stand die enowa AG vor ähnlichen Herausforderungen. Bei der Aufteilung eines bestehenden Java-EE-Projekts in fachliche Module konnten wir dabei bekannte Java-EE-Features aus der Perspektive der Modularisierung neu kennenlernen.

Vom Projekt zum Produkt

Modularität schafft Wiederverwendbarkeit – ein hohes Gut der Softwareentwicklung. Das betrifft nicht nur Methoden oder Klassen, auch ein ganzes Projekt rentiert sich oft erst dann, wenn ein daraus hervorgehendes Produkt auch weiteren Kunden angeboten werden kann. Dabei stellt sich jedoch rasch die Frage, wie die Aktivierung und Deaktivierung einzelner Features und deren Lizenzierung realisiert werden können. Oft ist es nötig, höchst individuelle Fachlichkeit eines Einzelkunden in das Projekt aufzunehmen, ohne dass dadurch die Ausführung für andere Kunden beeinflusst wird.

Ein gängiges Problem von Softwaremonolithen ist, dass die Kernapplikation zu viele Aufgaben aus den Bereichen Systemarchitektur, Fachlichkeit und Modulverwaltung übernimmt. Für ein solches Maven-Projekt ist in Listing 1 eine beispielhafte pom.xml aufgeführt. Das Artefakt core baut eine Abhängigkeit zu mehreren Featureartefakten auf. Was ist problematisch an diesem Vorgehen? Das Modul core ist durch den Ar...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang