Master 6.1 - Spring und Jakarta Deep Dive

Konkrete Spring Boot und Jakarta EE Module mit Code, Ablauf und kompakten SVGs.

Master 6.1 - Spring und Jakarta Deep Dive

Dieser Bereich erweitert Master 6 um konkrete Spring- und Jakarta-Module. Ziel ist nicht, beide Welten zu vermischen, sondern sie bewusst nebeneinander zu verstehen: Spring als stark integriertes Produktivitaets-Framework, Jakarta EE als portable Enterprise-Spezifikation.

Grundidee

Spring-Module zeigen REST, Validation, Security, Actuator, Worker und Integration-Flows. Jakarta-Module zeigen REST, CDI, Persistence, Messaging, Batch, Validation, Security und WebSocket. Beide greifen nur ueber Ports auf den fachlichen Kern zu.

Moduluebersicht

Modul	Zweck	Welt	Muster
spring-boot-api	Spring Boot REST API fuer Orders, Checkout, Validation und Fehlerantworten.	Spring	Adapter, DTO, Dependency Injection, Repository, Application Service
spring-boot-worker	Spring Boot Worker fuer Outbox, Retry und asynchrone Jobs.	Spring	Adapter, DTO, Dependency Injection, Repository, Application Service
spring-data-jpa-adapter	Spring Data JPA Adapter mit Repository-Abstraktion und Mapping.	Spring	Adapter, DTO, Dependency Injection, Repository, Application Service
spring-security-resource-server	Spring Security Resource Server mit Rollen- und Policy-Pruefung.	Spring	Adapter, DTO, Dependency Injection, Repository, Application Service
spring-observability-actuator	Spring Actuator, Health, Metrics und Trace-Kontext.	Spring	Adapter, DTO, Dependency Injection, Repository, Application Service
spring-modulith-events	Spring Modulith-nahe Event-Publikation und Modulgrenzen.	Spring	Adapter, DTO, Dependency Injection, Repository, Application Service
spring-integration-flow	Spring Integration Flow fuer Datei, Queue und HTTP-Kopplung.	Spring	Adapter, DTO, Dependency Injection, Repository, Application Service
spring-cloud-gateway-edge	Spring Cloud Gateway Edge Layer fuer Routing, Filter und Rate Limits.	Spring	Adapter, DTO, Dependency Injection, Repository, Application Service
jakarta-rest-api	Jakarta RESTful Web Services API fuer portable HTTP Endpunkte.	Jakarta	Adapter, DTO, Dependency Injection, Repository, Application Service
jakarta-cdi-application	Jakarta CDI Application Services mit Producer, Qualifier und Events.	Jakarta	Adapter, DTO, Dependency Injection, Repository, Application Service
jakarta-persistence-adapter	Jakarta Persistence Adapter mit Entity, Repository und Unit-of-Work.	Jakarta	Adapter, DTO, Dependency Injection, Repository, Application Service
jakarta-messaging-listener	Jakarta Messaging Listener fuer JMS/IBM MQ-kompatible Events.	Jakarta	Adapter, DTO, Dependency Injection, Repository, Application Service
jakarta-batch-jobs	Jakarta Batch Job-Struktur fuer Rechnungslaeufe und Importe.	Jakarta	Adapter, DTO, Dependency Injection, Repository, Application Service
jakarta-validation-module	Jakarta Validation Regeln fuer Commands, DTOs und Grenzen.	Jakarta	Adapter, DTO, Dependency Injection, Repository, Application Service
jakarta-security-module	Jakarta Security Rollen, Identity Store und Zugriffsmuster.	Jakarta	Adapter, DTO, Dependency Injection, Repository, Application Service
jakarta-websocket-notifications	Jakarta WebSocket Notifications fuer Live-Status und Betriebscockpit.	Jakarta	Adapter, DTO, Dependency Injection, Repository, Application Service

Ablauf Spring Boot

1. Request kommt am Controller an.

2. DTO wird validiert.

3. Controller erzeugt Command.

4. Use Case fuehrt fachlichen Ablauf aus.

5. Repository speichert Zustand.

6. Event oder Result wird erzeugt.

7. Actuator/Observability machen Betrieb sichtbar.

Ablauf Jakarta EE

1. Request oder Message erreicht Resource/Listener.

2. CDI injiziert Service, Repository und Event Bus.

3. Service verarbeitet Command.

4. Repository speichert Aggregate.

5. Event wird ueber CDI/JMS/WebSocket weitergegeben.

6. Antwort bleibt portable Jakarta API.

Warum beide in Master 6?

• Viele Enterprise-Landschaften haben Spring Boot Services neben Jakarta EE Anwendungen.

• OpenShift kann beide gleich betreiben, aber Build, Runtime, Health und Konfiguration unterscheiden sich.

• Architekturgrenzen muessen im Code sichtbar bleiben, sonst wird Framework-Code zum fachlichen Kern.

• Migrationen laufen oft ueber Koexistenz: neue Spring Edge Services, modernisierte Jakarta Services und gemeinsam genutzte Domain-Regeln.

Kompakte SVGs

• Spring Boot API Ablauf

• Spring Security Zugriff

• Spring Data Adapter

• Spring Observability

• Jakarta REST Ablauf

• Jakarta CDI Verdrahtung

• Jakarta Persistence

• Jakarta Messaging

• Spring und Jakarta Grenzen

• Hybrider Runtime Mix

• Validation Grenze

• Migration Spring Jakarta

Codebeispiel Spring

@RestController
@RequestMapping("/api/orders")
final class OrderController {
  // PATTERN: Adapter - HTTP wird in Command uebersetzt.
  private final PlaceOrderUseCase useCase;
  @PostMapping
  ResponseEntity<OrderResponse> place(@Valid @RequestBody OrderRequest dto) {
    return ResponseEntity.ok(useCase.handle(dto.toCommand()));
  }
}

Codebeispiel Jakarta

@Path("/orders")
@ApplicationScoped
class OrderResource {
  // PATTERN: CDI Service - portable Enterprise-Komponente.
  @Inject PlaceOrderService service;
  @POST
  OrderResponse place(@Valid OrderRequest dto) {
    return service.handle(dto.toCommand());
  }
}