Spring Enterprise Landkarte und Einordnung
Die Spring-Landschaft ist kein einzelnes Werkzeug, sondern ein Baukasten aus Kernframework, Boot-Automatismen, Datenzugriff, Security, Cloud-Patterns, Messaging, Batch, Testing und Observability.
Fachliche Einordnung
In Enterprise-Projekten scheitert Spring selten am einzelnen Annotationstrick. Schwieriger ist die Entscheidung, welches Projekt an welcher Schicht sitzt und welche Verantwortung bewusst nicht in dieselbe Klasse gehört.
Technische Darstellung
Kernkonzepte
- Framework vs Library: Framework ruft deinen Code nach seinem Lebenszyklus auf, Library wird gezielt von deinem Code genutzt.
- Boot als Start- und Produktionsrahmen, Framework als technisches Fundament.
- Spring Cloud, Integration, Batch und Security als spezialisierte Enterprise-Bausteine.
- Modulith als Mittelweg zwischen Big Ball of Mud und voreiligen Microservices.
Wann einsetzen?
- Du willst eine Systemlandkarte für ein neues Spring-Enterprise-Projekt erstellen.
- Du willst Legacy-Java-EE-Bausteine auf moderne Spring-Bausteine abbilden.
- Du willst entscheiden, welche Projekte Pflicht, optional oder nur für Spezialfälle sind.
Typische Fehler und Risiken
- Spring-Projekte nach Hype statt nach Verantwortung auswählen.
- Alle Probleme in Spring Boot Controller packen und später Microservices daraus schneiden wollen.
- Library und Framework verwechseln: ein Framework entscheidet über Lebenszyklus, Konventionen und Integrationstiefe.
Legacy- und Modernisierungssicht
EJB Services entsprechen häufig Application Services; JTA/JMS/SOAP/Batches werden schrittweise auf Spring Transactions, Integration/Stream, Web Services und Batch abgebildet.
Ausführliches Beispiel
Das Beispiel zeigt bewusst nicht nur Annotationen, sondern auch die Verantwortung der Schicht. In echten Projekten sollte der technische Spring-Code an Adapter- oder Konfigurationsrändern bleiben, während die Fachlogik testbar und möglichst frameworkarm bleibt.
Enterprise-Landkarte
Frameworks: Spring Framework, Spring Boot, MVC, WebFlux, Security, Batch, Integration, Cloud Stream, Modulith, GraphQL, Web Services, Statemachine, AI
Libraries: HATEOAS, REST Docs, Spring Kafka, Spring AMQP, Spring LDAP, Testcontainers, Micrometer
Merksatz: Je mehr Lebenszyklus, Konvention und Callbacks ein Baustein vorgibt, desto eher ist es ein Framework.
Checkliste für Reviews
- Ist die Verantwortung des Bausteins klar: Framework steuert Lebenszyklus, Library wird gezielt benutzt?
- Ist die Fachlogik außerhalb von Controller, Listener, Repository-Implementierung oder Konfiguration?
- Sind Fehlerfälle, Timeouts, Security, Monitoring und Tests sichtbar modelliert?
- Gibt es klare Grenzen zwischen DTO, Domäne, Persistence und Infrastruktur?