Cel i granice systemu#
System rezerwacji wizyt pozwala klientowi znaleźć usługę i wolny termin, zarezerwować go oraz otrzymać potwierdzenie. Usługodawca zarządza ofertą i dostępnością, a system zapobiega przydzieleniu jednego zasobu dwóm wizytom w tym samym czasie.
Model nie określa branży, płatności, konsultacji zdalnych, przepisów dotyczących danych wrażliwych ani szczegółowego regulaminu. W systemie medycznym, prawnym lub finansowym zakres danych i kontrola dostępu wymagają dodatkowych wymagań oraz przeglądu specjalistycznego. Tutaj skupiamy się na harmonogramie i stanie rezerwacji.
Role i cele#
Klient przegląda dostępne usługi, wybiera termin, rezerwuje, zmienia lub anuluje wizytę. Usługodawca publikuje dostępność, blokuje czas i obsługuje kalendarz. Administrator zarządza kontami i konfiguracją. Usługa powiadomień może wysyłać potwierdzenia i przypomnienia.
Granica systemu decyduje, czy kalendarz zewnętrzny jest częścią rozwiązania, czy aktorem. Nie zakładaj, że zewnętrzna integracja jest zawsze źródłem prawdy: ustal, który system rezerwuje slot i jak synchronizuje zmiany.
Model pojęciowy#
SlotTerminu reprezentuje konkretny czas dla usługodawcy lub zasobu. Rezerwacja wskazuje slot oraz usługę i ma status, np. oczekującą, potwierdzoną, anulowaną lub zakończoną. Jeżeli jedna wizyta wymaga kilku specjalistów lub pomieszczeń, model może potrzebować zestawu powiązanych zasobów zamiast jednego slotu.
Diagram nie przesądza, czy slot jest przechowywany z wyprzedzeniem, wyliczany dynamicznie z grafiku ani czy istnieje oddzielna encja harmonogramu. Tę decyzję podejmij na podstawie reguł dostępności, częstotliwości zmian i integracji.
Wyszukiwanie i rezerwacja#
Klient najpierw wyszukuje możliwe terminy; wynik jest migawką dostępności, nie gwarancją. Między odczytem a zatwierdzeniem inny klient może zająć slot. Dlatego system ponownie sprawdza i atomowo przydziela termin podczas tworzenia rezerwacji.
„Atomowo” oznacza, że konkurujące żądania nie mogą jednocześnie uznać tego samego slotu za wolny i zapisać dwóch aktywnych rezerwacji. Diagram wskazuje wymagane zachowanie, ale nie wybiera mechanizmu: może to zapewnić transakcja, ograniczenie unikalności lub inna kontrola współbieżności.
Potwierdzenia i anulowanie#
Ustal, czy rezerwacja jest natychmiast potwierdzona, czy oczekuje na akceptację usługodawcy lub płatność. Powiadomienie powinno wynikać z zapisanego stanu rezerwacji, a nie być traktowane jako dowód, że zapis się powiódł. Przy ponowieniu żądania po utracie odpowiedzi system powinien móc ustalić, czy rezerwacja istnieje, zamiast tworzyć duplikat.
Anulowanie zmienia status rezerwacji i może zwolnić slot. Reguła może zależeć od czasu do wizyty, płatności lub decyzji usługodawcy. Zmiana terminu powinna być operacją spójną: jeżeli nowy slot jest zajęty, stara rezerwacja nie może zniknąć bez potwierdzenia nowego terminu, chyba że klient świadomie anuluje ją osobno.
Cykl życia i reguły#
Maszyna stanów rezerwacji może obejmować Utworzona, Oczekująca, Potwierdzona, Anulowana, Zakończona i Nieodbyta. Slot ma niezależny stan, np. wolny, zablokowany lub zajęty. Blokada tymczasowa może wygasnąć; wtedy system powinien zwolnić czas zgodnie z regułą i bez naruszenia potwierdzonej rezerwacji.
Rozstrzygnij strefę czasową, zmianę czasu sezonowego, długość usług, przerwy, nakładające się zasoby, wyjątki kalendarza, nieobecności, listę oczekujących oraz widoczność informacji o kliencie. Te decyzje wpływają na dostępność i mogą wymagać osobnych modeli.
Testy wynikające z modelu#
- Wyszukiwanie zwraca terminy zgodne z usługą, zasobem i kalendarzem.
- Dwa równoczesne żądania na ten sam slot tworzą najwyżej jedną aktywną rezerwację.
- Ponowienie tego samego żądania nie tworzy duplikatu.
- Zmiana terminu nie zwalnia starego slotu przed udanym przydzieleniem nowego.
- Anulowanie zwalnia termin tylko wtedy, gdy reguła na to pozwala.
- Wygasła blokada nie usuwa potwierdzonej rezerwacji.
- Godziny są poprawnie interpretowane w strefie klienta i usługodawcy.
- Błąd powiadomienia nie zmienia statusu wizyty.
Typowe błędy#
- Utożsamienie wyszukania z rezerwacją. Lista dostępności nie blokuje terminu.
- Brak ochrony przed konfliktem. Dwa żądania mogą zająć ten sam slot.
- Status slotu i rezerwacji w jednym polu. To różne, choć powiązane cykle.
- Potwierdzenie przed zapisem. Powiadomienie nie może wyprzedzić udanej rezerwacji.
- Zmiana terminu bez transakcyjnych reguł. Klient może stracić oba terminy.
- Brak idempotencji. Retry po timeoutcie może utworzyć powtórną wizytę.
- Godzina bez strefy czasowej. Ten sam zapis może oznaczać różny moment.
- Założenie pojedynczego zasobu. Niektóre usługi wymagają kilku specjalistów lub pomieszczeń.
- Niejasne anulowanie i blokada tymczasowa. Zdefiniuj, kiedy slot wraca do puli.
Co studium pokazuje, a czego nie#
Model łączy pojęcia klienta, usługodawcy, usługi, slotu i rezerwacji z wyszukiwaniem oraz atomowym zajęciem terminu. Ujawnia decyzje o konfliktach, statusach, anulowaniu i czasie.
Nie jest gotowym systemem terminarzy ani kompletną specyfikacją prywatności, płatności i regulaminu. Zastąp założenia konkretnymi zasadami organizacji i uzupełnij model testami współbieżności oraz integracji.