Technologie-Katalog
Jede eingesetzte Technologie mit Zweck, Alternativen und Einordnung. Ziel: nicht nur zeigen WIE etwas benutzt wird, sondern auch WARUM diese und nicht eine andere Option.
Backend-Plattform
| Technologie | Version | Zweck | Alternativen (nicht gewählt) |
|---|---|---|---|
| Java | 21 (LTS) | Basis-Sprache; Records, Pattern Matching, sealed Classes seit 17 stabil verfügbar. Ursprünglich auf 17 gestartet, in Phase 9 auf die neuere LTS-Version migriert - reine --release-Änderung, keine Breaking Changes im übrigen Stack. |
Java 17 LTS (Vorgängerversion dieses Projekts, siehe Phase 9 in lernpfad.md) |
| Spring Boot | 3.3.x | Anwendungs-Framework; nutzt seit Version 3 durchgängig den jakarta.*-Namespace. |
Quarkus, Micronaut (beide native-image-optimiert, aber kleinere Community/weniger verbreitet in bestehenden Unternehmen) |
| Spring Cloud | 2023.0.x (Leyton) | Gateway, Config Server, Eureka, OpenFeign, LoadBalancer. | Eigenbau-Lösungen, Netflix-OSS direkt (größtenteils in "maintenance mode") |
| Maven | 3.9.x, Multi-Module-Reactor | Build-Werkzeug, Dependency Management via BOM. | Gradle (schneller bei großen Builds, aber Maven bei vielen Unternehmen Standard und deklarativer/einfacher lesbar für Lernzwecke) |
Persistenz & Caching
| Technologie | Zweck | Alternativen |
|---|---|---|
| PostgreSQL 16 | Relationale Datenbank je Bounded Context. | MySQL/MariaDB (ähnlich geeignet), MongoDB (falls Dokumentenmodell besser passen würde - hier nicht der Fall) |
| Flyway | Versionierte, nachvollziehbare Schemamigrationen (V1__...sql). |
Liquibase (XML/YAML-basiert, mächtiger aber komplexer) |
| Redis | Read-Through-Cache für die Katalogsuche (Phase 2). | Caffeine (In-Process-Cache, aber nicht über mehrere Service-Instanzen geteilt) |
| Spring Data JPA / Hibernate | Persistenz-Mapping. | jOOQ (typsicheres SQL, weniger "magisch", aber mehr Boilerplate) |
Messaging
| Technologie | Zweck | Alternativen |
|---|---|---|
| Apache Kafka (KRaft-Modus) | Event-Bus für Domain Events. | Amazon SQS/SNS, Google Pub/Sub (Cloud-gebunden), Redpanda (Kafka-API-kompatibel, leichtgewichtiger) |
| RabbitMQ | Task-/Command-Queues mit DLQ. | Amazon SQS, ActiveMQ Artemis |
Security
| Technologie | Zweck | Alternativen |
|---|---|---|
| Keycloak | OAuth2/OIDC Identity Provider. | Auth0, Okta, Azure AD/Entra ID (alle Cloud/SaaS-gebunden), eigene Lösung (siehe ADR-0004) |
| Spring Security (Resource Server) | JWT-Validierung in jedem Service. | - |
Resilience & Kommunikation
| Technologie | Zweck | Alternativen |
|---|---|---|
| Resilience4j | Circuit Breaker, Retry, Bulkhead (Phase 3). | Netflix Hystrix (End of Life, nicht mehr empfohlen) |
| OpenFeign | Deklarative REST-Clients für Service-zu-Service-Aufrufe. | RestClient/WebClient direkt (mehr Kontrolle, mehr Boilerplate) |
Frontend
| Technologie | Zweck | Alternativen |
|---|---|---|
| Angular 22 | SPA-Framework (Standalone Components, Signals). In zwei Etappen von 18 hochgezogen, siehe angular-update-migration.md. | React, Vue (beide verbreitet; Angular gewählt, da "batteries included" - Router/HTTP/Forms/DI ohne Zusatzbibliotheken - und im Enterprise-Umfeld verbreitet) |
| NgRx (punktuell) | State-Management-Vertiefung in einem bewusst ausgewählten Feature. | Signals-basiertes State-Management (wird als Standard im übrigen Frontend genutzt, zum Kontrast) |
| Keycloak-Angular / angular-oauth2-oidc | OIDC-Login (Authorization Code + PKCE) im Browser. | - |
Infrastruktur & Betrieb
| Technologie | Zweck | Alternativen |
|---|---|---|
| Podman / Podman Compose | Lokale Infrastruktur (rootless, daemonless; siehe infra/docker-compose.yml - Dateiname bleibt, podman compose liest ihn unverändert). Kein Lizenzthema (Apache 2.0), siehe kapazitaetsplanung 8.6. |
Docker Desktop (kompatibel, aber kommerziell ab Unternehmensgröße), Rancher Desktop, nerdctl+containerd |
| Kubernetes + Helm | Produktionsnahes Deployment-Profil (Phase 7). Was ein ECHTER Betrieb bei 1 Mio. Buechern/100.000 Nutzern an Cluster-/DB-/Messaging-Dimensionierung und Lizenzkosten braeuchte: kapazitaetsplanung-skalierung.md. | Docker Swarm (einfacher, aber weniger verbreitet in Unternehmen), Nomad |
| kind (Kubernetes-in-Docker) | Echter, lokal laufender Kubernetes-Cluster für die Jenkins-Test-Stufe (Phase 11, siehe kind-cluster.md) - läuft mit KIND_EXPERIMENTAL_PROVIDER=podman in der vorhandenen Podman-Installation, ohne separate VM. |
Minikube (ähnlich, aber eigene VM/Treiber-Schicht), k3d (k3s-in-Docker, ähnlich schlank), CodeReady Containers/OKD (in dieser Umgebung an abgelaufenen Zertifikaten und RAM-Konflikten gescheitert, siehe kubernetes-guide.md) |
| GitHub Actions (Beispiel-Workflows) | CI/CD-Pipeline-Beispiele: Build/Test/Lint bei jedem Push. | GitLab CI |
| Jenkins | Vierstufige Deploy-Pipeline mit Approval-Gate (Local/Test/QS/Prod, siehe ADR-0009) - zusätzlich zu GitHub Actions, nicht als Ersatz. Seit Phase 12 projektübergreifend zentral in enterprise-workspace/shared/enterprise-infrastructure/ betrieben statt projektlokal, siehe reverse-proxy.md. |
Spinnaker, Argo CD (spezialisierte Deployment-/GitOps-Werkzeuge, für dieses Lernprojekt "eine Technologie zu viel") |
| Traefik | Reverse-Proxy mit Label-basiertem Service-Discovery (Phase 12) - macht lokale Dienste unter sprechenden .localhost-Hostnamen statt localhost:<port> erreichbar, projektübergreifend über ein gemeinsames externes Container-Netzwerk (Traefiks "docker"-Provider spricht Podmans Docker-kompatible API). Läuft in enterprise-workspace/shared/enterprise-infrastructure/, siehe reverse-proxy.md. |
nginx-proxy (ähnliches Label-Prinzip, weniger eingebaute Features), Caddy (einfache Konfiguration, aber schwächere Container-Provider-Integration) |
| Prometheus + Grafana | Metriken/Dashboards. | Datadog, New Relic (SaaS, kostenpflichtig) |
| Zipkin (via Micrometer Tracing) | Distributed Tracing. | Jaeger (ähnlich verbreitet, OpenTelemetry-natives Backend) |
Testing & Qualität
| Technologie | Zweck | Alternativen |
|---|---|---|
| JUnit 5 + AssertJ + Mockito | Unit-Tests. | TestNG (weniger verbreitet im Spring-Umfeld) |
| Testcontainers | Integrationstests gegen echte Infrastruktur (in Podman-Containern) statt Mocks. Setup siehe docker-compose-guide.md. | H2 In-Memory-DB (schneller, aber verhält sich nicht wie Postgres - "works on H2, fails on Postgres" ist ein bekanntes Problem) |
| ArchUnit | Architektur-Fitness-Functions. | - |
| Playwright (Phase 8) | Browser-E2E-Tests. | Cypress, Selenium |
| k6 (Phase 8) | Lasttests. | JMeter, Gatling |
| JaCoCo | Code-Coverage pro Modul (seit Phase 1) und reactor-weit aggregiert mit CI-Schwellenwert (coverage-report-Modul). |
Cobertura (unmaintained), OpenClover |
| Pact-JVM | Consumer-Driven Contract Testing zwischen den Services (REST + Kafka-Events), siehe teststrategie.md. | Pact Broker (eigene Infrastruktur statt eingecheckter Dateien - für dieses Lernprojekt bewusst nicht gewählt), Spring Cloud Contract (stärker an Spring gekoppelt, weniger polyglott) |
Bewusst NICHT verwendet (mit Begründung)
| Technologie | Warum nicht |
|---|---|
| Lombok | Moderne Java-17-Records/kompakte Konstruktoren decken die meisten Lombok-Anwendungsfälle (Getter, equals/hashCode, Builder) bereits ohne Annotation-Processing-"Magie" ab - besser nachvollziehbar für Lernende, die den generierten Code sonst nie sehen. |
| Avro + Confluent Schema Registry | Schlankere Infrastruktur durch einfache JSON-Events mit manuellem schemaVersion-Feld (Trade-off in ADR-0003 diskutiert) - Avro/Schema-Registry als "Vertiefungsaufgabe" im DevOps-Kapitel erwähnt. |
| GraphQL | REST passt besser zum Ziel, klassische Enterprise-Integrationsmuster (Circuit Breaker, Gateway-Routing, OpenAPI) zu zeigen, die im REST-Umfeld Standard sind. |