Vorwort

Dieser Beitrag beschäftigt sich mit verschiedenen Möglichkeiten an Projektstrukturen, die mir bisher über den Weg gelaufen sind. Zu allen werde ich die Vor- und Nachteile erörtern und zusammenfassen darstellen, wann ich welche Struktur für sinnvoll erachte.

Bei meinen Betrachtungen gehe ich innerhalb eines Projekts von den Standards aus, die maven bereits definiert, so dass die Pfade für Sources, Resources, etc einerseits nicht in Frage gestellt werden und andererseits die Grundlage für zusätzliche Pfade liefern, sofern notwendig.

Das Monolithische Projekt

Jeder wird es kennen und hier geteilter Meinung sein über den Sinn oder Unsinn eines Monolithischen Projekts. Zugegebenermaßen bin ich kein großer Freund monolithischer Projekte, weil sie die Angewohnheit haben durch erweiterte Anforderungen zu wachsen bzw, unkontrolliert zu wuchern. In den meisten Fällen steht dann die Funktionalität im Vordergrund, so dass niemand Zeit hat aus einem monolithischen Projekt ein modulares Projekt zu machen.

Aber monolithische Projekte haben ihre Daseinsberechtigung, z.B. für Code Beispiele, Prototypen, Workshops, Machbarkeitsstudien oder Bibliotheken. Dabei sollte es aber auch bleiben.

Vorteile:

• monolithische Projekte sind schnell angelegt und man kann schnell mit der eigentlichen Entwicklung beginnen.

Nachteile:

• monolithische Projekte werden schnell unübersichtlich
• bei den Strukturen im Projekt kommt es schnell zu Wildwuchs, da innerhalb eines monolithischen Projekts jeder auf jedes Package zugreifen kann
• eine Modularisierung oder ein Refactoring sind später häufig nur schwer möglich

Das modulare Projekt

Im Gegensatz zum monolithischen Projekt besteht ein Projekt aus mehreren Modulen. Dabei ist ein modulares Projekt so aufgebaut, dass jedes Modul eine technische oder fachliche in sich abgeschlossene Einheit bildet, die in anderen Modulen wiederverwendet werden kann. Beispiele wären ein Persistenz-Layer (technisches Modul) oder ein Authentifizierungsmechanismus (fachliches Modul).
Bei einem modularen Projekt gibt es immer ein Modul, das Parent-Modul, das sich um die Abhängigkeiten für das gesamte Projekt kümmert, sowie mindestens ein Modul, das auf der gewünschten Zielumgebung installiert werden kann. Die anderen Module werden in den anderen Modulen direkt oder transitiv benötigt.
Vorteile

• die einzelnen Module könne auch in anderen Projekten wieder verwertet werden
• Code ist übersichtlicher und besser wertbar, da jedes Modul eine in sich geschlossene Einheit ist

Nachteile

• Das Anlegen eines Projekts ist komplizierter als beim Monolithen
• bei schlechter Struktur können zirkuläre Abhängigkeiten entstehen