Unterschiedliche jar Dateien zusammen führen

[OnDemand]

Hallo zusammen,

ich habe eine Anforderung, welches es nun nötig macht mein Programm ein wenig aufzuteilen. So brauche ich ein Modul für Rechnungen schreiben, eines für Bestellungen verwalte und eine Lagerverwaltung.

Aktuell wäre es so, dass ich alles in eine .jar packen würde, typischer Monolith. Wir kommen von Microservices, das war keine gute Lösung da wir ein kleines Team sind. Nun aber die Überlegung ob man nicht pro Modul ein jar File macht also je ein eigenständiges Projekt.

Es gibt ja spezielle Modulframeworks dafür. Hat jemand Erfahrungen wann das Sinn macht in Module aufzuteilen? Aktuell ist wie gesagt alles in einem und läuft auch tadellos. Nur sollen später noch mehr Module dazu kommen, daher jetzt schon eine Überlegung ob der aktuelle Weg richtig ist.

 

[mihe7]

Wir sind auch ein kleines Team, haben mehrere Anwendungen unter der Fuchtel und sind somit gezwungen, es so pragmatisch wie möglich zu halten. Für alles, was irgendwie stört, aufhält oder unsinnig erscheint, suchen wir nach Lösungen, um das abzustellen.

Wir haben durchaus Module im Sinne von eigenen Projekten, die werden aber alle per Maven-Dependency zur Anwendung hinzugefügt, so dass am Ende ein Monolith entsteht. Wir stellen also keine unterschiedlichen Anwendungen zusammen, vielmehr haben wir eine kleine Admin-Oberfläche, über die ein Nicht-Entwickler die Module (i. S. des Vertriebs) aktiviert.

Das ist für unsere Bedürfnisse der zur Zeit optimale Weg. Sollte sich das ändern, passen wir das Vorgehen halt an.

 

[OnDemand]

Wir stellen also keine unterschiedlichen Anwendungen zusammen, vielmehr haben wir eine kleine Admin-Oberfläche, über die ein Nicht-Entwickler die Module (i. S. des Vertriebs) aktiviert.

So ähnlich haben wir es auch, User bucht Module und entsprechend wird das Modul in der DB hinterlegt als bestellt. Im Frontend kann er es dann eben aufrufen und nutzen oder bekommt ne Meldung "nicht gebucht".

 

[Neumi5694]

So ähnlich haben wir es auch, User bucht Module und entsprechend wird das Modul in der DB hinterlegt als bestellt. Im Frontend kann er es dann eben aufrufen und nutzen oder bekommt ne Meldung "nicht gebucht".

Mehrere Jars zu erstellen, ist jetzt nicht die große Herausforderung, schlimmstenfalls wird im Script für die eine ein gewisses Package weggelassen und eine andere beinhaltet nur dieses.
Aber ich würde stattdessen gleich jetzt schon eine ordentliche Lizenzverwaltung mit einbauen und das Ganze nicht anhand fehlender Jars oder Klassen organisieren.

 

[OnDemand]

Aber ich würde stattdessen gleich jetzt schon eine ordentliche Lizenzverwaltung mit einbauen und das Ganze nicht anhand fehlender Jars oder Klassen organisieren.

Machen wir ja nicht, sondern es gibt eine Tabelle "modules" da sind gebuchte module drin. Die Module sind dann entweder nutzbar oder nicht

 

[mihe7]

Vielleicht mal andersrum gefragt: welches Problem willst Du lösen?

 

[OnDemand]

Ehrlich gesagt hab ich bisher kein Problem. Ich möchte nur ausloten, ob es bessere Möglichkeiten gibt um Module einzubinden. Nicht, dass wir in ein paar Monaten Probleme bekommen und dann alle Module die bis dann gebaut wurden, nochmal neu anfassen müssen weil die "Modularisierung" nicht funktioniert.

 

[mihe7]

Mit der Maven-Dependency funktioniert es halt wie bei jeder anderen Lib auch

 

[Neumi5694]

Ich sag's mal so .... damit schaffst du dir nur neue Probleme, die du nicht brauchst. Wenn du bereits eine gute Kontrolle darüber hast, wer was darf, bzw. gebucht hat, dann kannst du genausogut EIN Produkt anbieten, das bei jedem Kunden gleich ausschaut. Der Platzverbrauch der Jars rechtfertigt das Aufteilen jedenfalls nicht.Ein praktischer Grund für's Aufteilen wäre z.B., wenn du 2 Programme hättest, die auf die gleichen Kernlibraries zugreifen oder der höchste aller Gründe, die Übersichtlichkeit. Ansonsten hast du da wirklich keinen Vorteil.