Spezifikation / Library-APIData1.0
Jakarta NoSQL
Jakarta NoSQL standardisiert Zugriff auf NoSQL-Datenbanken über gemeinsame Konzepte.
Einordnung
Spezifikation / Library-API
Enterprise-Rolle
Es ist relevant, wenn Enterprise-Anwendungen dokumenten-, key-value-, spalten- oder graphorientierte Stores integrieren.
Fachliches Verständnis
Es ist relevant, wenn Enterprise-Anwendungen dokumenten-, key-value-, spalten- oder graphorientierte Stores integrieren. In der Praxis ist wichtig, die Spezifikation nicht mit der konkreten Runtime zu verwechseln. Der Standard beschreibt die portablen APIs, die Implementierung entscheidet über Konfiguration, Performance, Betrieb und Support.
Kernkonzepte
- NoSQL-Datenbanktypen.
- Repository/Template-artige Zugriffe je Implementierung.
- Vendor-Unterschiede bleiben wichtig.
Typische Einsatzfälle
- Dokumentenbasierte Projektionen.
- High-volume Reads.
- Polyglot Persistence.
Technisches Beispiel
java
@ApplicationScoped
public class OrderProjectionWriter {
public void updateProjection(OrderPlaced event) {
// Dokument-/Key-Value-Projektion bewusst getrennt vom transaktionalen Kern.
Document doc = Document.of("orderId", event.id(), "status", "PLACED");
documentCollection.insert(doc);
}
}
Architekturregel: Jakarta APIs gehören an Systemgrenzen und Infrastrukturpunkte. Fachentscheidungen bleiben in Application Services und Domain-Modellen testbar und möglichst unabhängig vom Container.
Enterprise-Fallen
- NoSQL als Ersatz für Modellierung.
- Transaktionsannahmen aus RDBMS übertragen.
Legacy-Modernisierung
Legacy-Reporting oder Suchprojektionen können getrennt vom transaktionalen Kern in NoSQL-Stores wandern.
Vertiefung: Review-Fragen für Senior-Entwickler
- Welche Spezifikation ist hier wirklich nötig?
- Welche Runtime-Funktion wird genutzt und ist sie portabel?
- Wo liegt die Transaktionsgrenze?
- Sind API-Verträge, DTOs und Domain-Modelle getrennt?
- Ist der Code ohne Application Server testbar?