Architekturübersicht

ShuttleFlow ist als mandantenfähige Webanwendung für den Vereinsbetrieb aufgebaut. Ziel der Architektur ist ein stabiler und leicht bedienbarer Betrieb für Turniertage, ohne lokale Installation auf Vereinsrechnern.

Systemkontext

• Benutzer: Turnierleitung, Vereinsadministration, Spieler mit Leserechten, öffentliche Besucher (z. B. Notice-Preview).
• Kernfunktion: Planung, Durchführung und Auswertung von Badmintonturnieren in verschiedenen Modi.
• Betriebsmodell: Browserbasierte Nutzung, zentrale Datenhaltung, mandantengetrennte Organisation.

Zentrale Komponenten

• Web-UI und Anwendungsschicht: Java/Vaadin-Anwendung mit den Domänenbereichen Turniere, Spieler, Teams, Matches, Courts und Registrierungen.
• Persistenzschicht: ORM-basierte Datenzugriffe (Hibernate) auf relationale Datenhaltung (PostgreSQL).
• Statische Informationsseiten: getrennte statische App für Website-Inhalte, Hilfe und Dokumentation.
• Integrationslogik: Anbindung externer Quellen (z. B. NuLiga-Import) über kontrollierte Service-Workflows.

Daten- und Request-Fluss (vereinfacht)

1. Ein Benutzer ruft die Anwendung oder eine statische Infoseite über HTTPS auf.
2. Die Anwendungslogik validiert Eingaben und ordnet Operationen einem Mandantenkontext zu.
3. Domänenoperationen (z. B. Runde erzeugen, Ergebnis speichern) werden transaktional in der Datenbank gespeichert.
4. UI-Ansichten und Druck-/Aushangdaten werden aus dem aktuellen Turnierstand abgeleitet.

Mandanten- und Rollenmodell

• Mandantentrennung: Jeder Verein arbeitet in einem eigenen Datenkontext.
• Rollen: Administratoren mit Schreib- und Verwaltungsrechten, Standardbenutzer typischerweise mit Leserechten.
• Betriebsrelevanz: Das Modell ermöglicht parallelen Betrieb mehrerer Vereine ohne Datenvermischung.

Betriebs- und Deploy-Modell

• Anwendungs-Deploy: Java-WAR als Cloud-Foundry-App.
• Website-Deploy: Statische Seiten als separate Cloud-Foundry-App.
• Routing: Trennung von App-Route (Anwendung) und Website-Route (Dokumentation/Informationsseiten).
• Skalierung: Instanz- und Ressourceneinstellungen pro App unabhängig steuerbar.

Qualitätsziele der Architektur

• Nachvollziehbarkeit: Klare Trennung von Domänenbereichen und Betriebsrollen.
• Wartbarkeit: Schrittweise Erweiterung um neue Turnierlogiken (z. B. Swiss-/Tie-Break-Regeln).
• Betriebsstabilität: Definierte Deploy-Artefakte und reproduzierbare Release-Pfade.
• Datenschutzorientierung: Keine Veröffentlichung sicherheitskritischer Betriebsdetails in der öffentlichen Doku.

Bewusst nicht veröffentlicht

Aus Sicherheits- und Betriebsgründen enthält diese Seite absichtlich keine Details zu internen Schlüsseln, Secret-Handling, konkreten Konfigurationswerten, Admin-Endpunkten oder Infrastruktur-internen Netzwerkpfaden.

Für die fachliche Nutzung der Anwendung siehe Hilfe und Quickstart.