Komponenten und Schnittstellen

Frontend, Backend und Datenbank werden fachlich gemeinsam entwickelt, technisch aber klar voneinander getrennt. Jede Komponente besitzt einen eindeutigen Verantwortungsbereich.

Vue-3-Frontend

Das Frontend ist eine eigenständige Single-Page-Anwendung auf Basis von Vue 3 und TypeScript. Es ersetzt die bisherigen JSF-, Facelets-, RichFaces- und Dojo-Komponenten.

Zu seinen Aufgaben gehören:

• Darstellung und Navigation der Benutzeroberfläche,
• Visualisierung des dreidimensionalen Wissensraums,
• Erfassung und clientseitige Vorprüfung von Benutzereingaben,
• Aufruf der Backend-API,
• Darstellung von Validierungsfehlern und Bearbeitungszuständen,
• Einleitung und Pflege der Browser-Anmeldesitzung mit Keycloak.

Das Frontend enthält keine verbindliche Fachlogik und besitzt keinen direkten Datenbankzugriff. Angaben aus dem Browser werden vom Backend erneut validiert.

Spring-Boot-Backend

Das Backend wird als eigenständige Spring-Boot-Anwendung mit Java 21 oder einer neueren LTS-Version entwickelt. Es ersetzt die Laufzeit aus Tomcat 7, Weld, JSF und der historischen Jersey-Integration.

Seine Verantwortlichkeiten sind:

• Bereitstellung der fachlichen HTTP-API,
• Ausführung der Geschäftsregeln,
• Authentifizierungs- und Autorisierungsprüfungen mit Spring Security,
• Transaktionssteuerung,
• Zugriff auf die Datenbank,
• Validierung eingehender Daten,
• Erzeugung konsistenter Fehler- und Antwortformate,
• Bereitstellung von Health-, Metrik- und Diagnoseinformationen.

Das Backend soll als modularer Monolith aufgebaut werden. Eine Aufteilung in Microservices ist nicht Teil des initialen Zielbilds. Fachliche Modulgrenzen sollen dennoch im Code sichtbar sein, damit spätere Entscheidungen nicht durch unnötige Kopplung eingeschränkt werden.

Datenbank

Die relationale Datenbank bleibt das führende System für fachliche Business-Flies-Daten. Das Backend ist der einzige reguläre Zugriffspunkt für Frontend-Anfragen.

Für den Schema-Lifecycle gilt:

• Flyway verwaltet alle Schemaänderungen.
• Migrationen werden gemeinsam mit dem Backend versioniert und geprüft.
• Bereits ausgeführte Migrationen werden nicht nachträglich verändert.
• Bestehende Legacy-Installationen erhalten eine dokumentierte Flyway-Baseline.
• Backup und Restore werden vor produktiven Schemaänderungen berücksichtigt.

Die konkrete Datenbank- und Versionsentscheidung wird separat getroffen. Bestehende MySQL-spezifische Views, Trigger, Stored Procedures und SQL-Abfragen müssen bei dieser Entscheidung berücksichtigt werden.

Keycloak

Keycloak ist ein gemeinsam genutzter Identitätsdienst außerhalb der drei Hauptkomponenten. Das Frontend verwendet den OpenID-Connect-Authorization-Code-Flow. Das Backend validiert Bearer Tokens und bildet Claims beziehungsweise Keycloak-Rollen auf Anwendungsberechtigungen ab.

Fachliche Benutzerdaten können weiterhin in Business Flies liegen. Sie werden über die stabile Keycloak-Subject-ID mit der zentralen Identität verknüpft. Passwörter werden nicht mehr durch Business Flies oder einen Tomcat Realm geprüft.

HTTP-API

Die Schnittstelle zwischen Frontend und Backend soll folgende Grundsätze erfüllen:

• HTTPS ist für externe Kommunikation verpflichtend.
• Nutzdaten werden in dokumentierten JSON-Formaten ausgetauscht.
• Endpunkte verwenden konsistente Statuscodes und Fehlerformate.
• Autorisierung wird serverseitig für jeden geschützten Vorgang geprüft.
• API-Änderungen werden so gestaltet, dass Frontend und Backend kontrolliert aktualisiert werden können.
• Technische Details der Persistenz werden nicht in die öffentliche API übertragen.

Die bestehenden Legacy-Endpunkte dienen während der Migration als fachliche Referenz. Sie müssen nicht unverändert als langfristige API übernommen werden.