Sport, Freizeit & Clubbetrieb
Ein Club ist kein Webauftritt, sondern ein Betrieb
Für die NICE RACKET GmbH ist eine Plattform entstanden, die den öffentlichen Auftritt und den täglichen Betrieb im selben System führt: Plätze und Buchungen, Turniere und Ranglisten, Ligabetrieb, Kasse, Personal und Schichten – mit einem Rollen- und Rechtemodell, das von Anfang an Teil des Entwurfs war.
- Auftraggeber
- NICE RACKET GmbH
- Projekt
- NICE RACKET CLUB
- Branche
- Sport, Freizeit & Clubbetrieb
- Art
- Digitale Plattform · Buchung · Clubbetrieb
82 Seitenrouten im Frontend
31 Tabellen im Datenmodell
2 Sportarten: Padel und Pickleball
Die Angaben auf dieser Seite sind am Quelltext, am Datenbankschema und an der ausgelieferten Anwendung geprüft.
Ausgangslage
Worum es geht
Ein Racket-Club verkauft keine Produkte, sondern Zeitfenster. Der Betrieb hängt daran, dass Plätze belegt sind, Turniere stattfinden, Ligen laufen und jemand weiß, wer wann arbeitet. Jede dieser Fragen hat üblicherweise ein eigenes Werkzeug – und keines weiß vom anderen.
Dazu kommt der öffentliche Auftritt: Preise, Öffnungszeiten, Standorte, Team, Partner, Veranstaltungen. Liegen diese Inhalte in einem anderen System als der Betrieb, pflegt jemand beides doppelt – und eine Seite ist immer veraltet.
Und über allem steht die Zugriffsfrage. Mitglieder, Trainerinnen und Trainer, Kapitäne, Aushilfen und die Verwaltung sehen dieselbe Plattform, aber nicht dasselbe darin.
Was XINOO umgesetzt hat
- Die öffentliche Clubwebsite mit über 80 Seitenrouten, einschließlich eigener Bereiche für Padel und Pickleball, Preise, Standorte, Team, Partner, FAQ und Veranstaltungen.
- Den Betriebsteil: Platz- und Buchungsverwaltung, Turnier- und Ligabetrieb mit Ranglisten und Spielvermittlung, Kassenfunktionen für den Verkauf vor Ort sowie Personal-, Schicht- und Zeitverwaltung.
- Die tragende Schicht darunter: Anmeldung mit Rollen und Rechten, Anmeldeschutz, Protokollierung, redaktionell pflegbare Seitenbausteine und eine zeitgesteuerte Hintergrundverarbeitung.
Vorgehen
Was vor der ersten Zeile Code stand
Die teuersten Fehler entstehen nicht beim Programmieren, sondern davor – wenn niemand geklärt hat, welche Vorgänge das System eigentlich abbilden soll.
Der Betrieb zuerst, die Seiten danach
Am Anfang stand nicht die Frage, welche Seiten die Website braucht, sondern welche Vorgänge der Club täglich führt: Platz belegen, Partie vermitteln, Turnier ansetzen, Schicht planen, vor Ort kassieren. Erst daraus ergab sich, welche Daten es geben muss – und welche Seiten sie sichtbar machen.
Zwei Sportarten, ein Platzmodell
Padel und Pickleball unterscheiden sich in Spielweise und Zielgruppe, teilen sich aber Anlage, Zeitfenster und Buchungslogik. Statt zweier getrennter Bereiche entstand ein Platzmodell, das beide Sportarten trägt und den öffentlichen Auftritt getrennt auftreten lässt.
Wer darf was sehen
Vor der ersten Funktion wurde festgelegt, welche Rollen es gibt und woran sie sich unterscheiden. Das Rechtemodell entstand dadurch als Struktur und nicht als nachträgliche Sammlung von Ausnahmen.
Bestandsaufnahme der Fremdsysteme
Geprüft wurde, was zugekauft und was entwickelt wird. Für Buchung, Kasse und Personal fiel die Entscheidung auf eigene Entwicklung, weil diese Bereiche so eng ineinandergreifen, dass eine Anbindung mehr Abgleich erzeugt hätte, als sie erspart.
Gestaltung
Die Handschrift des Kunden, nicht die der Agentur
Die Marke des Clubs, nicht die der Agentur
Der Auftritt folgt der Bildsprache des Clubs: dunkle Grundfläche, kräftiger Akzent, sportliche Fotografie. XINOO hat diese Sprache in ein digitales Produkt übersetzt, nicht durch eine eigene ersetzt.
Buchen ist der Hauptweg
Die Platzbuchung ist auf jeder Seite in Reichweite. Alles andere – Team, Partner, FAQ – ordnet sich darunter ein. Eine Clubseite, auf der man das Buchen suchen muss, verfehlt ihren Zweck.
Ein Bausteinsatz für 80 Seiten
Bei über achtzig Routen entscheidet nicht das Einzellayout, sondern der Bausteinsatz. Karten, Listen, Tabellen und Formulare stammen aus einem gemeinsamen Satz – neue Bereiche entstehen dadurch ohne neuen Entwurf.
Zuerst das Telefon
Gebucht wird unterwegs, oft kurz vor dem Spiel. Buchungswege, Zeitraster und Übersichten sind für schmale Geräte entworfen und wachsen zum Desktop hin, nicht umgekehrt.
Architektur
Die Entscheidungen dahinter
Nicht der Funktionsumfang entscheidet, ob ein System trägt, sondern wie es geschnitten ist.
Eine Anwendung, zwei Gesichter
Öffentlicher Auftritt und Verwaltungsportal liegen in derselben Anwendung auf demselben Datenbestand. Preise, Standorte und Veranstaltungen werden einmal gepflegt und erscheinen an beiden Stellen.
Inhalte als Bausteine
Seiteninhalte liegen als redaktionelle Bausteine in der Datenbank statt im Code. Eine Änderung an Öffnungszeiten oder Preisen braucht keine Auslieferung.
Rollen vor Funktionen
Das Rechtemodell liegt als eigene Tabellenstruktur vor – Rollen, Rechte und ihre Zuordnung getrennt, nicht als Merkmal am Benutzerkonto. Neue Funktionen erben dadurch eine bestehende Ordnung, statt eine neue zu erfinden.
Arbeit außerhalb des Anfrageweges
Was dauert oder wiederkehrt – Erinnerungen, Kalenderdateien, Massenverarbeitung – läuft über eine Auftragsschlange und eine Zeitsteuerung, nicht im Anfrageweg des Besuchers.
Systemaufbau
Von außen nach innen
Die Ebenen des Systems in der Reihenfolge, in der eine Anfrage sie durchläuft.
Besucherinnen und Besucher
Öffentliche Clubwebsite mit Plätzen, Preisen, Veranstaltungen, Team und Kontakt.
Anwendung
React-Oberfläche mit über 80 Routen – öffentlicher Bereich und Verwaltungsportal in einer Anwendung.
Fachlogik
Buchung, Turniere, Liga, Kasse, Personal und Schichten als eigene Dienste der API.
Zugriffsschicht
Anmeldung, Rollen und Rechte, Anmeldeschutz und Protokollierung – vor jedem schreibenden Zugriff.
Daten und Hintergrund
Relationales Datenmodell mit 31 Tabellen, dazu Auftragsschlange und Zeitsteuerung für wiederkehrende Arbeit.
Funktionen
Was das System kann
Gruppiert nach Bereichen. Die Aufstellung ist die Antwort auf die Frage, wie groß das Vorhaben tatsächlich war.
Spielbetrieb
- Platz- und Buchungsverwaltung
- Turniere mit Verwaltung und Übersicht
- Ranglisten und Punktekonto
- Spielvermittlung für offene Partien
- Ligabetrieb mit Team- und Kapitänsansichten
- Spielerprofile
Öffentlicher Auftritt
- Bereiche für Padel und Pickleball
- Preise, Standorte und Öffnungszeiten
- Team-, Partner- und Sponsorenseiten
- Veranstaltungen inkl. Kalenderdateien
- FAQ und redaktionelle Seitenbausteine
- Kontaktanfragen mit vorlagenbasiertem Mailversand
Betrieb vor Ort
- Kassenfunktionen mit Kategorien und Vorgängen
- Produkt- und Artikelverwaltung
- Personalverwaltung
- Schichtplanung
- Zeitkonten und Abwesenheiten
- Verwaltungsportal mit Übersicht
Zugriff und Nachvollziehbarkeit
- Anmeldung mit Rollen und Rechten
- Anmeldeschutz mit Sperrlogik
- Erzwungener Kennwortwechsel und Kennworthistorie
- Erneuerbare Sitzungsmerkmale
- Protokoll sicherheitsrelevanter Vorgänge
- Mehrere Standorte im Rechtemodell abgebildet
Automatisierung
- Zeitgesteuerte Hintergrundverarbeitung
- Auftragsschlange für längere Vorgänge
- Erinnerungen und Benachrichtigungen
- Kalenderdateien zu Veranstaltungen
- Vorlagenbasierter Mailversand
Technik
Womit es gebaut ist
Oberfläche
Anwendungsschicht
Betrieb
Angebunden
Integration
Was angebunden ist – und was nicht
Die entwickelte Plattform kommt für Kasse, Personal und Betrieb bewusst ohne Fremdsysteme aus: Diese Bereiche greifen so eng ineinander, dass eine Anbindung mehr Abgleich erzeugt hätte, als sie erspart. Angebunden ist, was außerhalb liegt – Mailversand für Anfragen und Benachrichtigungen sowie Kalenderdateien für Veranstaltungen. Die öffentliche Platzbuchung läuft im Live-Betrieb über CircleSquare; die Buchungsverwaltung der Plattform bleibt davon unberührt.
Sicherheit & Zugriff
Sicherheit ist Teil des Entwurfs
Wer Zugriffsrechte nachträglich einzieht, baut Ausnahmen. Wer sie vorher entwirft, baut eine Struktur.
Anmeldung mit Rollen und Rechten
Rollen, Rechte und ihre Zuordnung liegen als eigene Tabellen mit Verknüpfungen vor. Ein Zugang bekommt eine Rolle, nicht eine Sammlung einzeln gesetzter Häkchen.
Schutz des Anmeldewegs
Fehlversuche werden erfasst, Konten lassen sich sperren, ein Kennwortwechsel kann erzwungen werden, und die Kennworthistorie verhindert die Wiederverwendung. Sitzungen laufen über erneuerbare Zugriffsmerkmale.
Kennwörter als Prüfwert
Kennwörter werden ausschließlich als Prüfwert gespeichert und nie im Klartext gehalten. Die Prüfung beim Anmelden erfolgt gegen diesen Wert.
Datenbankzugriffe durchgängig gebunden
Sämtliche Datenbankabfragen laufen über vorbereitete Anweisungen mit gebundenen Werten – im gesamten API-Bestand über 280 Stellen. Eingaben werden dadurch als Werte behandelt und nicht als Bestandteil der Abfrage.
Protokollierung
Sicherheitsrelevante Vorgänge werden in einem eigenen Protokoll festgehalten – die Voraussetzung dafür, im Zweifelsfall nachvollziehen zu können, was passiert ist.
Woran sich die Umsetzung orientiert
- Secure by Design – das Rechtemodell entstand vor den Funktionen, nicht danach
- Least Privilege – Rollen erhalten die Rechte ihrer Aufgabe, nicht die des Systems
- Defense in Depth – Anmeldeschutz, Rechteprüfung, gebundene Abfragen und Protokoll greifen unabhängig voneinander
- An OWASP-Grundsätzen orientierte Anwendungssicherheit bei Authentifizierung, Eingabebehandlung und Zugriffskontrolle
Diese Grundsätze beschreiben die Arbeitsweise. Sie sind keine Zertifizierung und werden hier auch nicht als solche dargestellt.
Was geprüft wurde
- Die IT-Sicherheit war ausdrücklicher Bestandteil des Projekts und wurde geprüft.
- Am Quelltext nachvollziehbar sind: durchgängig gebundene Datenbankabfragen, Kennwortspeicherung als Prüfwert, Sperrlogik nach Fehlversuchen, erzwungener Kennwortwechsel, Kennworthistorie sowie ein eigenes Protokoll sicherheitsrelevanter Vorgänge.
- Eine formale Zertifizierung ist damit nicht verbunden und wird nicht behauptet.
Stand
Was läuft, was noch nicht
Ein Projekt ist selten an einem Stichtag fertig. Der Stand steht hier, weil er zur Sache gehört.
Die Plattform ist entwickelt und unter eigener Adresse mit HTTPS ausgeliefert, einschließlich automatischer Zertifikatserneuerung.
Die öffentliche Clubwebsite ist live: Plätze, Preise, Gutscheinvarianten, Veranstaltungen, Team und Kontakt. Die Platzbuchung läuft dort über CircleSquare.
Der Verkaufsbereich besteht derzeit aus der Oberfläche; ein Bezahl- und Bestellweg ist nicht angebunden. Er wird deshalb nicht als Funktion geführt.
Die öffentliche Anmeldung zur Business-Liga hing an einem fremden Dienst, der nicht mehr antwortet. Der Ligabetrieb selbst ist entwickelt; dieser eine Zugangsweg wird ersetzt.
Öffentlich erreichbar unter nice-racket-club.de (öffnet in neuem Tab).
Verwandte Themen
Weiterlesen
Ein vergleichbares Vorhaben?
Schildern Sie die Ausgangslage. Wir ordnen ein, welche Ebene zuerst dran ist und ob dafür ein Produkt, eine Integration oder eine Entwicklung das richtige Mittel ist.