text: Spring Base Project by Wizi - Wizis Blog
  Spring Base Project by Wizi
  Repository: blog-spring-boot-base-project
  Tags: java, spring, lombok, base
  In diesem Beitrag möchte ich meine Projektstruktur vorstellen.
  Bei meinen Projekten handelt es sich um Java / Gradle / Spring Boot Projekte. Die Basis der Projekte stellt somit immer das File build.gradle da. In diesem File findet ihr die Konfiguration für die gesamte Applikation.
  Schon seit einigen Jahren verwendet ich als Entwicklungsumgebung IntelliJ IDEA, habe aber auch schon mit der Spring Tool Suite bzw. Eclipse gearbeitet. Da ich IntelliJ IDEA sowohl privat als auch in der Arbeit verwende, werde ich in meinen Beiträgen auch nur auf diese Entwicklungsumgebung eingehen.
  Da es sich bei den Projekten jedoch um Gradle Projekte handelt, könnt ihr diese auch in allen anderen Java Entwicklungsumgebungen mit Gradle Unterstützung öffnen (gegebenenfalls ist das File build.gradle anzupassen).
  Wie schon in meinem Beitrag "Environments mit Spring Profiles steuern" erwähnt braucht ihr aber für meine Beispiel Projekte gar keine IDE um die Applikation starten zu können. Java reicht immer aus, da ich den gradle wrapper mit ins Repository gebe (wie es auch üblich ist).
  Das funktioniert mit ./gradlew build bzw. gradlew.bat build. Das ausführbare jar befindet sich dann in build/libs/. Mit Windows würde ich es jedoch mit java -jar spring-profiles.jar starten, da die Applikation sonst im Hintergrund gestartet wird und nur mehr über den Task Manager beendet werden kann.
  In den meisten Projekten verwende ich Lombok, d.h. ihr müsst Annotation Processing in IntelliJ IDEA aktivieren und eventuell das Lombok Plugin installieren, solltet ihr das Projekt in IDEA öffnen und bauen wollen.
  Mit Lombok müsst ich euch nicht mehr selber um Getter, Setter, toString, equals oder hashCode Methoden kümmern, da diese zur compile Zeit vom Lib erzeugt werden.
  Für die Strukturierung des Java Codes verwende ich package by layer, d.h. ich teile meine Klasses nach ihrer Verwendung in Packages ein (Services, Repositories, Controller, DTOs, Configs, etc). Auch wenn ich über die Jahre auch einige Male package by feature ausprobiert habe, finde ich package by layer in den meisten Projekten passender bzw. übersichtlicher.