Cel i granica przykładu#

Modelujemy klienta, który rezerwuje wizytę u specjalisty lub w punkcie usługowym. System wyszukuje dostępne sloty, próbuje zająć wybrany termin i tworzy potwierdzenie. Przykład skupia się na konkurencji: dwóch klientów może wybrać ten sam slot niemal równocześnie.

Nie określamy tu konkretnej branży, regulaminu odwołań, płatności, przypomnień, długości wizyty ani ochrony danych szczególnych. Te wymagania mogą zmienić model i powinny być wyraźnie doprecyzowane przed implementacją.

Uczestnicy i pojęcia#

Klient inicjuje rezerwację; Interfejs przyjmuje kryteria i wyświetla wynik; Usługa rezerwacji koordynuje sprawdzenie slotu oraz zapis; Kalendarz lub repozytorium dostępności przechowuje terminarz; Powiadomienia może wysłać potwierdzenie poza podstawową ścieżką.

Termin (slot) jest konkretnym przedziałem przypisanym do specjalisty lub zasobu. Rezerwacja łączy klienta, slot i usługę, przechowuje status oraz dane kontaktowe. Sam wynik wyszukiwania nie gwarantuje, że termin pozostanie dostępny do chwili zatwierdzenia.

Przebieg podstawowy#

  1. Klient podaje kryteria, np. usługę, lokalizację i preferowaną datę.
  2. System zwraca dostępne terminy zgodne z kryteriami.
  3. Klient wybiera slot i przesyła żądanie rezerwacji.
  4. Usługa ponownie sprawdza dostępność i atomowo zajmuje slot.
  5. System zapisuje rezerwację i zwraca potwierdzenie.
Klient wyszukuje terminy, wybiera slot, a usługa rezerwacji atomowo sprawdza i zajmuje go; system potwierdza rezerwację albo informuje, że termin został zajęty.
Rezerwacja terminu z obsługą konkurencyjnej próby zajęcia tego samego slotu.

Metoda zajmijAtomowo podkreśla decyzję architektoniczną: kontrola i zajęcie muszą być nierozdzielne z punktu widzenia konkurujących żądań. Schemat „sprawdź, a potem zapisz” w dwóch niezależnych krokach może dopuścić podwójną rezerwację. Diagram nie przesądza, czy atomowość zapewnia transakcja bazy, blokada, unikalny indeks czy inny mechanizm.

Reguły, które trzeba uzgodnić#

  • Czy slot należy do konkretnego specjalisty, pomieszczenia czy zestawu zasobów?
  • Czy jedna rezerwacja może obejmować kilka kolejnych slotów?
  • Czy system utrzymuje czasową blokadę podczas wypełniania formularza?
  • Jak klient potwierdza rezerwację i kiedy staje się ona ostateczna?
  • Co dzieje się przy równoczesnej próbie zajęcia terminu?
  • Czy rezerwacja może oczekiwać na płatność lub potwierdzenie?
  • Jak działają anulowanie, zmiana terminu, nieobecność i lista oczekujących?
  • Czy strefa czasowa i zmiany czasu sezonowego wpływają na zapis terminu?

Modeluj każde z tych zachowań, jeśli należy do zakresu. Nie zakładaj, że terminy przechowywane jako lokalne daty i godziny będą jednoznaczne w systemie działającym w wielu strefach czasowych.

Stany rezerwacji#

Rezerwacja może przechodzić przez stany Utworzona, Oczekująca na potwierdzenie, Potwierdzona, Anulowana, Zakończona lub Nieodbyta. Dostępność slotu jest powiązana, ale nie zawsze tożsama ze statusem rezerwacji. Przy odwołaniu slot może wrócić do kalendarza; przy oczekiwaniu na płatność może być blokowany tymczasowo.

Ustal, co dzieje się po timeoutcie, ponowieniu żądania i utracie odpowiedzi po udanym zapisie. Klucz idempotencji lub odczyt statusu mogą zapobiec utworzeniu kilku rezerwacji, gdy klient ponawia żądanie z powodu problemu sieciowego.

Testy wynikające z modelu#

  • Wyszukanie pokazuje tylko terminy spełniające kryteria.
  • Dwa równoczesne żądania na ten sam slot tworzą najwyżej jedną aktywną rezerwację.
  • Ponowienie tego samego żądania nie tworzy duplikatu.
  • Konflikt dostępności prowadzi do czytelnej odpowiedzi i ponownego wyboru.
  • Anulowanie zwalnia slot zgodnie z uzgodnioną regułą.
  • Zmiana terminu zachowuje spójność starego i nowego slotu.
  • Utrata odpowiedzi po zapisie pozwala ustalić, czy rezerwacja istnieje.
  • Daty, strefy czasowe i zmiana czasu są obsłużone zgodnie z wymaganiami.

Typowe błędy#

  • Uznanie listy terminów za gwarancję rezerwacji. Dostępność może zmienić się między odczytem a zapisem.
  • Nieatomowe sprawdzenie i zajęcie. Powstaje ryzyko podwójnego terminu.
  • Brak obsługi konfliktu. Klient może otrzymać fałszywe potwierdzenie.
  • Niejasny moment potwierdzenia. Ustal, czy rezerwacja istnieje przed płatnością lub akceptacją.
  • Pominięcie powtórzeń żądań. Retry może utworzyć duplikat.
  • Nieokreślone anulowanie i zwolnienie terminu. Status rezerwacji i kalendarza rozchodzą się.
  • Brak strefy czasowej. Godzina może oznaczać różne chwile dla klienta i systemu.
  • Przeładowanie jednego diagramu. Płatność, przypomnienia i zmiana terminu mogą wymagać osobnych widoków.

Co przykład pokazuje, a czego nie#

Przykład przedstawia podstawowy przebieg wyszukiwania i zatwierdzania terminu oraz alternatywę, w której slot został zajęty przez inne żądanie. Podkreśla różnicę między wyświetleniem dostępności a skutecznym, spójnym zapisem.

Nie stanowi pełnej specyfikacji kalendarza, płatności, danych osobowych ani polityki odwołań. Rozbuduj go o diagram stanów i wymagania dotyczące transakcyjności, idempotencji oraz czasu, jeśli są potrzebne w konkretnej domenie.