TableFlow: Zwei zusammengestellte Tische dürfen nicht dreifach verfügbar sein

Eine große Gruppe verändert den Tischplan

Ein Restaurant stellt für sechs Personen zwei kleinere Tische zusammen. Wenn das Buchungssystem weiterhin beide Einzeltische als frei behandelt, entsteht trotz hübscher Kalenderansicht eine Überschneidung. Die vorhandene Skrabi-Projektbeschreibung TableFlow umfasst Räume, Tische, Tischarten und Kapazität. Daraus kannst du einen präzisen Bauauftrag für kombinierbare Plätze ableiten. Der folgende Vorschlag beschreibt eine gewünschte Regel; er behauptet keine bereits funktionierende Reservierungssoftware oder tatsächliche Tischverfügbarkeit.

Mit drei Karten statt einer großen Tabelle beginnen

Zeichne Tisch A mit vier Plätzen, Tisch B mit zwei Plätzen und eine Kombination AB. Schreibe auf die dritte Karte, dass sie dieselben physischen Ressourcen nutzt. AB ist damit kein zusätzliches Möbelstück. Notiere, welche Kombinationen betrieblich erlaubt sind und welche Wege frei bleiben müssen. Solche Regeln kann ein Entwickler nicht zuverlässig aus der Gesamtzahl der Sitzplätze erraten. Für die erste Probe genügt ein erfundener Raum ohne echte Gästedaten.

Lege im Auftrag fest, dass eine Reservierung nicht nur eine Personenzahl belegt, sondern konkrete Ressourcen für einen Zeitraum. Berücksichtige dabei die vereinbarte Aufenthaltsdauer und gegebenenfalls eine Vorbereitungspause. Das verhindert, dass eine Folgegruppe schon eingeplant wird, während der Tisch noch umgebaut werden muss.

Den Konflikt verständlich zeigen

Beschreibe zwei parallele Anfragen: Eine Gruppe möchte AB, eine andere im selben Zeitraum A. Der Server muss bei der endgültigen Bestätigung genau eine widerspruchsfreie Zuordnung speichern. Eine Prüfung allein beim Öffnen des Formulars reicht dafür nicht, weil zwischen Anzeige und Absenden eine andere Reservierung eintreffen kann. Die zurückgewiesene Anfrage braucht eine klare Erklärung und gegebenenfalls einen anderen Termin, keine allgemeine Fehlermeldung ohne Handlungsweg.

Ein manueller Eingriff durch den Empfang sollte ebenfalls prüfbar bleiben. Wenn eine Zuordnung geändert wird, müssen alte Ressourcen freigegeben und neue gemeinsam reserviert werden. Ein Zwischenzustand mit beiden belegten Varianten kann die Übersicht sonst unnötig blockieren.

Die Abnahme braucht Überschneidungen

Ergänze den TableFlow-Bauauftrag um diese Probe: Reserviere AB, versuche gleichzeitig A, verschiebe die erste Reservierung und prüfe anschließend A erneut. Teste auch eine angrenzende Uhrzeit mit und ohne Umbaupuffer. In der mobilen Empfangsansicht müssen die betroffenen Tische erkennbar sein, ohne auf Farbe allein angewiesen zu sein. Die Planung ist erfolgreich, wenn alle Beteiligten erklären können, welche echte Ressource gerade gebunden ist. Ob die spätere Anwendung das atomar durchsetzt, wird an den Testfällen überprüft.