Orchestrator/bahn/project-audit/analysis/iteration-02-technical-deepdive.md

Iteration 02 — Technischer Deep Dive: Ergebnisse

Stand: 2026-04-22 | Basis: 23 pom.xml + 1 package.json der Kern-Services

---

1. Versionen und Abhaengigkeiten

Zentrale Versionen (aus bestellsystem-parent-pom)

Komponente	Version	Status	Risiko
Java	17 (Parent) / 21 (Services)	Migration laeuft	MITTEL — Parent noch auf 17, Services auf 21
Spring Boot	3.5.13	EOL Juni 2026!	KRITISCH — Upgrade auf 4.x dringend
Camunda 8	8.8.22	Aktuell	OK — Upgrade auf 8.9 geplant
PostgreSQL Driver	42.7.10	Aktuell	OK
Flyway	11.20.3	Aktuell	OK
Log4j2	2.25.4	Aktuell	OK
Jackson	2.21.2	Aktuell	OK
OpenAPI Generator	7.21.0	Aktuell	OK
Cucumber	7.34.3 (Parent) / 7.23.0 (SV)	Divergenz!	NIEDRIG — aber Inkonsistenz
JUnit	5.14.3	Aktuell	OK
WireMock	3.13.2	Aktuell	OK
MapStruct	1.6.3	Aktuell	OK
OpenTelemetry	2.27.0 (Parent) / 2.26.1 (SV)	Divergenz	NIEDRIG
AWS SDK	2.42.34 (SV)	Aktuell	OK
Angular	21.2.4	Aktuell	OK
TypeScript	~5.9.2	Aktuell	OK
RxJS	7.8.2	Aktuell	OK

Aktive CVE-Patches (aus pom.xml Kommentaren)

CVE	Bibliothek	Fix-Version
CVE-2025-48924	commons-lang3	3.20.0
CVE-2025-53864	nimbus-jose-jwt	10.9
CVE-2025-66566	lz4-java	1.11.0
CVE-2026-1002	vertx-core	4.5.26
CVE-2025-12183	lz4-java (Kafka)	at.yawk fork
CVE-2026-40477/78	thymeleaf (Togglz)	Excluded
GHSA-* (diverse)	tomcat-embed-core	10.1.54
GHSA-3pxv-*	log4j-core	2.25.4

2. Architektur-Bewertung

Parent-POM Struktur

• bestellsystem-parent-pom (v0.12.50-SNAPSHOT): Zentrale Versionsverwaltung fuer alle Services
• GroupId: com.dbnetz.bestellsystem
• Definiert Spring Boot, Logging, Monitoring, OpenAPI, Test-Dependencies zentral
• Problem: Parent-POM hat java.version=17, aber die meisten Services ueberschreiben auf 21
• Problem: Einige Services (SV) haben eigene Parent-POMs statt den gemeinsamen zu nutzen

Steuerung-Vertrieb (Komplexester Service)

• 18 Maven-Module! (testutils, model-process, model, tdm-utils, kafka-utils, i18n, api-adapter, persistence, monitoring-utils, process-configuration, camunda-interface, camunda8, application, camunda8-jobworker, assemblies, kit, kafka, feature-toggle)
• Eigener Parent-POM (nicht bestellsystem-parent-pom)
• Camunda 8.8.22 integriert
• Lombok + MapStruct
• Feature Toggles via Togglz
• AWS SDK fuer MSK/Kafka
• 10+ interne API-Dependencies (trassenanmeldung, versandauftrag, versandergebnis, etc.)

Auftrags-Verwaltung-Trasse

• Nutzt bestellsystem-parent-pom (v1.8.0) als Parent
• Kafka-Integration (Spring Kafka 3.3.14)
• OAuth2 Resource Server (Spring Security)
• Feature Toggles via Togglz
• Signature-Database + Signature-Message (Nachrichtensignierung)
• OpenAPI Code-Generierung aus data-model

Portal UI

• Angular 21.2.4 (sehr aktuell)
• Eigene UI-Library: @kuk/kuk-ui-library
• Portal-API: @bestellsystem/portal-api v4.0.0
• OIDC Auth: angular-auth-oidc-client
• PDF-Generierung: jspdf + jspdf-autotable
• Cypress fuer E2E-Tests
• Karma + Jasmine fuer Unit-Tests

3. Dependency-Graph (vereinfacht)

bestellsystem-parent-pom (v0.12.50)
  |
  +-- auftrags-verwaltung-trasse (v1.7.1)
  |     +-- auftragsverwaltung-api (v6.0.0)
  |     +-- auftraege-api (v6.0.0)
  |     +-- event-model-api (v3.3.0)
  |     +-- data-model (v10.0.0)
  |     +-- signature-database (v1.5.0)
  |     +-- signature-message (v1.7.0)
  |     +-- logging-util (v1.3.0)
  |
  +-- stammdaten-bereitstellung
  +-- kundendaten-bereitstellung
  +-- rabattnummern-bereitstellung
  +-- archivierungsservice
  +-- common-interface
  +-- taftap-tdm-konverter
  +-- tbv-absicherung-konverter
  +-- vertragsdaten-verteiler

steuerung-vertrieb (EIGENER Parent, v1.6.1)
  |
  +-- trassenanmeldung-api (v8.11.0)
  +-- versandauftrag-api (v3.11.0)
  +-- versandergebnis-api (v2.14.0)
  +-- vertriebsauftraege-api (v8.3.0)
  +-- produktionsauftrag-api (v3.5.0)
  +-- eventmodel-api (v3.2.0)
  +-- kundendaten-api (v2.9.0)
  +-- objectinfomessage-api (v2.11.0)
  +-- data-model (v10.0.0)
  +-- camunda-events (v2.2.0)
  +-- signature-message (v1.7.0)
  +-- core-components-common (v1.6.1)
  +-- core-components-kafka (v1.2.1)

portal-ui (Angular 21, v1.9.1)
  +-- @bestellsystem/portal-api (v4.0.0)
  +-- @kuk/kuk-ui-library (v0.45.0)

4. Technische Gesundheits-Scorecard

Kategorie	Bewertung	Details
Java-Version	🟡	21 in Services, aber Parent noch auf 17. Inkonsistenz.
Spring Boot	🔴	3.5.13 — EOL Juni 2026. Upgrade auf 4.x ist KRITISCH.
Camunda	🟢	8.8.22 — aktuell, Upgrade auf 8.9 geplant
Angular	🟢	21.2.4 — sehr aktuell
Dependencies	🟢	Renovate aktiv, CVEs werden gepatcht
Versionskonsistenz	🟡	SV hat eigenen Parent-POM, Cucumber/OTel Versionen divergieren
Modularitaet	🟡	SV mit 18 Modulen sehr komplex, andere Services einfacher
API-Versionierung	🟢	Saubere OpenAPI-basierte Versionierung (data-model v10.0.0)
Security	🟢	Aktive CVE-Patches, Signature-Libs, OAuth2, Mutual SSL
Feature Toggles	🟢	Togglz integriert in SV und AV
Monitoring	🟢	OpenTelemetry, Micrometer, Prometheus integriert
Testing	🟡	Cucumber + JUnit + WireMock, aber Testkonzept in Ueberarbeitung (ADR-70)

5. Handlungsempfehlungen (priorisiert)

KRITISCH

1. Spring Boot 4 Upgrade — EOL 3.5 ist Juni 2026. Muss sofort beginnen. Betrifft ALLE Services.
2. Parent-POM Konsolidierung — SV sollte den gemeinsamen Parent nutzen oder die Divergenz bewusst dokumentieren.

HOCH

3. Java-Version im Parent auf 21 anheben — Alle Services nutzen bereits 21, Parent hinkt hinterher.
4. Cucumber-Version vereinheitlichen — 7.34.3 vs 7.23.0 zwischen Parent und SV.
5. SV-Modularitaet pruefen — 18 Module ist sehr viel. Gibt es Konsolidierungspotenzial?

MITTEL

6. OpenTelemetry-Version synchronisieren — 2.27.0 vs 2.26.1
7. Testkonzept-Modernisierung — ADR-70 ist in Arbeit, Umstieg von Cucumber auf Plain JUnit in Teilen geplant
8. data-model v10.0.0 — Zentrale Abhaengigkeit, Aenderungen haben Breitenwirkung