42 lines
2.8 KiB
Markdown
42 lines
2.8 KiB
Markdown
# Technisches Zielbild – Terminbuchungskalender (SOLL)
|
||
|
||
## Architekturprinzip
|
||
|
||
Der Kalender wird als wiederverwendbare technische Basis für zwei getrennte Instanzen PW und PS umgesetzt. Die Oberfläche darf keine fachlichen Daten, Geheimnisse oder Buchungsentscheidungen dauerhaft im Browser halten. Termine, Kapazitäten, Anmeldungen, Bestätigungen, Erinnerungen, Exporte und Kalenderfeeds benötigen eine serverseitige Geschäftslogik und persistente Datenhaltung.
|
||
|
||
Die konkrete Betriebsform bleibt offen: Integration in ein bestehendes System oder eigenständiges Tool mit eigener Laufzeit, Datenbankmodell und Verwaltungsoberfläche. Unabhängig davon müssen Oberfläche, Geschäftslogik, Datenzugriff, Benachrichtigung und Kalenderfeed voneinander getrennt bleiben.
|
||
|
||
## Konfiguration und Vorschau
|
||
|
||
Die Verwaltungsoberfläche erlaubt das Anlegen, Bearbeiten und Löschen von Terminen sowie die Pflege ihrer Parameter. Während einer Konfigurationsänderung wird eine Live-Vorschau der jeweiligen Kalenderinstanz angezeigt, damit sich die sichtbare Wirkung ohne Zwischenschritt prüfen lässt.
|
||
|
||
## Buchungslogik und Konsistenz
|
||
|
||
Eine Buchung muss die Kapazität atomar prüfen und nach Bestätigung erhöhen. Gleichzeitige Anfragen dürfen nicht zu mehr bestätigten Teilnahmen als der definierten Kapazität führen. Entfernt eine durchführende Person eine Teilnahme, wird die Kapazität korrekt neu berechnet oder freigegeben.
|
||
|
||
Bestätigung, Erinnerungen und iCalendar-Aktualisierung sind aus bestätigten Buchungszuständen abzuleiten. Wiederholte technische Ausführung derselben Aufgabe darf nicht zu mehrfachen Erinnerungen oder doppelten Bestätigungen führen.
|
||
|
||
## Schnittstellen
|
||
|
||
Erforderlich sind mindestens Schnittstellen oder Dienste für:
|
||
|
||
- Termin- und Konfigurationsdaten,
|
||
- Anfragen, Bestätigungen und Kapazitätsprüfung,
|
||
- Versand von Bestätigungs- und Erinnerungsnachrichten,
|
||
- abonnierbare iCalendar-Feeds je Instanz,
|
||
- Export bestätigter Teilnahmen nach Zeitraum,
|
||
- Prüfung bzw. Anzeige historischer Teilnahmen bei Mehrfachanmeldungen.
|
||
|
||
## Teststrategie
|
||
|
||
Geschäftsregeln erhalten Unit-Tests. Integrations-Tests prüfen Datenzugriff, Kapazitätsgrenzen, Bestätigung, Kalenderfeed, Export und Benachrichtigungsplanung. End-to-End-Tests prüfen den sichtbaren Ablauf von Kalender, Anmeldung, Bedingungen für Probearbeiten und Rückmeldungen.
|
||
|
||
## Checkpoints
|
||
|
||
- [ ] Betriebsform, Datenbank und Verwaltungsoberfläche sind entschieden.
|
||
- [ ] Die Schnittstellen zwischen Oberfläche und Geschäftslogik sind spezifiziert.
|
||
- [ ] Die Atomarität der Kapazitätsprüfung ist technisch nachweisbar getestet.
|
||
- [ ] Versand, Erinnerung und iCalendar-Aktualisierung sind idempotent umgesetzt.
|
||
- [ ] Die Live-Vorschau ist Teil der Konfigurationsoberfläche getestet.
|
||
- [ ] Für jede fachliche Regel existiert ein automatisierter Test.
|