Jakarta Data, Repository Pattern und Portabilität
Jakarta Data als Standardisierungsschritt, Repository-Abstraktion und portabler Umgang mit Persistenz.
Repository nicht mit CRUD verwechseln
Ein Repository ist fachlich motiviert. Es speichert und lädt Aggregates oder Projektionen. Eine generische CRUD-Schnittstelle ist in komplexen Domänen oft zu schwach.
Jakarta Data
Jakarta Data standardisiert Repository-ähnliche Persistenzkonzepte innerhalb der Jakarta-EE-Welt. V4 behandelt es als Standardisierungsoption, nicht als Zwang für jede Architektur.
Portabilität
Portabilität entsteht nicht nur durch APIs, sondern durch disziplinierte Grenzen: Domain kennt keine Provider-Annotationen, Queries sind gekapselt, Integrationsverträge sind getestet.
Praxisübertragung auf das V4-Beispielprojekt
Entscheidung
Dokumentiere die getroffene Architekturentscheidung als ADR, inklusive Alternativen, Folgen und Betriebsrisiken.
Code-Nachweis
Markiere verwendete Entwurfsmuster direkt im Code und ergänze sie in docs/design-patterns.md.
Betrieb
Definiere Metrik, Alert, Runbook-Schritt und Rollback-Option für diesen Bereich.
Typische Fehlerbilder
- Framework-Feature wird eingesetzt, ohne fachliche Grenze zu verstehen.
- Technische Wiederholung wird nicht idempotent gemacht.
- Observability wird erst nach Produktionsproblem ergänzt.
- Tests prüfen nur Happy Path und keine Wiederanläufe.