31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
# Datenmodell – Terminbuchungskalender (Mockup)
|
||
|
||
## Gegenwärtiges Mockup-Datenmodell
|
||
|
||
Das Mockup besitzt kein persistentes Datenmodell. Es verwendet nur flüchtige Beispielobjekte für Slots. Ein Beispiel-Slot enthält:
|
||
|
||
- `id`: technisch eindeutige Beispielkennung,
|
||
- `project`: `perspektivwerk` oder `produktionsschule`,
|
||
- `date`: Datum im Format `YYYY-MM-DD`,
|
||
- `start`: Startzeit im Format `HH:MM`,
|
||
- `title`: sichtbare Bezeichnung der Terminart,
|
||
- `status`: `available` oder `booked`.
|
||
|
||
Die Slots sind die einzige dauerhafte Information im Quellcode. Sie sind Testdaten und keine tatsächlichen Verfügbarkeiten.
|
||
|
||
## Flüchtige Anfragedaten
|
||
|
||
Der Anfrage-Dialog verarbeitet Name, E-Mail-Adresse, Telefonnummer, Alter, Nachricht, Ansprechperson und Zustimmungsstatus nur im Browser. Diese Werte werden weder als Buchung noch als Anfrageobjekt angelegt und nach dem Schließen des Dialogs verworfen.
|
||
|
||
## Fachlich noch nicht modelliert
|
||
|
||
Das Mockup enthält keine Entitäten für Buchung, Reservierung, Bestätigung, Stornierung, Terminraum, Mitarbeitende, Kalenderfeed, E-Mail oder Löschfristen. Auch Beziehungen zwischen Terminarten, Dauer, Ressourcen und Verfügbarkeitsregeln sind nicht modelliert.
|
||
|
||
## Checkpoints
|
||
|
||
- [ ] Es ist definiert, was einen buchbaren Slot fachlich eindeutig identifiziert.
|
||
- [ ] Es ist entschieden, welche Buchungszustände benötigt werden.
|
||
- [ ] Es ist festgelegt, welche Daten zu einer Anfrage gespeichert werden dürfen.
|
||
- [ ] Es ist geklärt, ob Räume, Mitarbeitende oder weitere Ressourcen modelliert werden müssen.
|
||
- [ ] Es existiert ein fachlich bestätigtes Datenmodell einschließlich Aufbewahrungs- und Löschregeln.
|