Next Architektur
Die Next-Architektur beschreibt das technische Zielbild für die modernisierte Business-Flies-Anwendung. Analog zur ETE-Plattform wird das System in drei klar getrennte Hauptkomponenten gegliedert:
- ein eigenständiges Frontend,
- ein eigenständiges Backend,
- eine relationale Datenbank.
Die Komponenten werden als getrennte Workloads in einem Kubernetes-Cluster betrieben. Sie besitzen eigene Laufzeit-, Konfigurations- und Skalierungsgrenzen, bilden fachlich aber weiterhin eine gemeinsame Anwendung.
Zielbild
| Komponente | Vorgesehene Technologie | Verantwortung |
|---|---|---|
| Frontend | Vue 3 und TypeScript | Benutzeroberfläche und Visualisierung im Browser |
| Backend | Java 21+, Spring Boot und Spring Security | Fachlogik, REST-API, Autorisierung und Persistenzzugriff |
| Datenbank | Relationale Datenbank mit Flyway | Fachliche Daten, Schema und versionierte Migrationen |
| Identitätsdienst | Keycloak mit OpenID Connect | Anmeldung, Single Sign-on und zentrale Identitäten |
| Plattform | Kubernetes | Deployment, Konfiguration, Vernetzung und Betrieb |
Zusammenspiel
- Der Browser lädt das Vue-Frontend über einen HTTPS-Endpunkt des Clusters.
- Die Anmeldung erfolgt über Keycloak mit OpenID Connect.
- Das Frontend sendet fachliche Anfragen mit einem Zugriffstoken an die Backend-API.
- Spring Security validiert das Token und prüft die erforderlichen Rollen und Berechtigungen.
- Das Backend führt die Fachlogik aus und greift auf die relationale Datenbank zu.
- Flyway bringt das Datenbankschema kontrolliert auf den zum Backend-Release passenden Stand.
- Das Backend liefert strukturierte JSON-Antworten an das Frontend zurück.
Direkte Zugriffe des Frontends auf die Datenbank sind nicht vorgesehen. Das Backend bildet die einzige fachliche Schnittstelle zwischen Benutzeroberfläche und Persistenz.
Wesentliche Architekturziele
- Frontend und Backend sind technisch getrennt und unabhängig baubar.
- Fachlogik und Autorisierungsentscheidungen liegen im Backend, nicht im Browser.
- Die Backend-Schnittstellen sind explizit dokumentiert und versionierbar.
- Konfiguration und Secrets werden zur Laufzeit durch Kubernetes bereitgestellt.
- Container-Images sind unveränderlich und enthalten keine umgebungsspezifischen Zugangsdaten.
- Das Datenbankschema wird ausschließlich durch versionierte Flyway-Migrationen weiterentwickelt.
- Keycloak ersetzt die bisherige datenbankbasierte Tomcat-Authentifizierung.
- Logs, Metriken und Health Endpoints sind in die Betriebsplattform integrierbar.
- Frontend, Backend und Datenbank können getrennt gesichert, aktualisiert und überwacht werden.
Abgrenzung zur Legacy-Architektur
| Legacy | Next |
|---|---|
| Gemeinsames WAR mit serverseitiger JSF-Oberfläche | Getrenntes Vue-Frontend und Spring-Boot-Backend |
| Externer Tomcat 7 mit Java 8 | Eigenständiger Backend-Container mit Java 21+ |
| JSF, RichFaces und Dojo | Vue 3 und TypeScript |
| CDI mit Weld und JAX-RS mit Jersey | Spring Dependency Injection und definierte HTTP-API |
Tomcat DataSourceRealm | Keycloak und Spring Security |
| Historischer Schema-Bootstrap | Flyway-Migrationen |
| Containerkonfiguration in Tomcat | Kubernetes ConfigMaps, Secrets und deklarative Ressourcen |
| Manuell zusammengestelltes WAR | Reproduzierbare Maven- und Frontend-Builds |
Kapitel
Planungsstand
Die Seite beschreibt das angestrebte Zielbild. Einzelheiten wie Datenbankversion, Komponentenbibliothek, konkrete API-Verträge, Kubernetes-Paketierung und Skalierungsparameter werden im Verlauf der Migration festgelegt und anschließend in dieser Dokumentation präzisiert.