Pony Academy — Platforma rezerwacji dla szkoły jazdy konnej
Przyjazna strona, planowanie dostępności i zaplecze oparte na Aurum
Przegląd
Dedykowana strona Nuxt i moduł rezerwacji Aurum, które łączą ofertę lekcji, dostępność koni i instruktorów, płatności online, konta klientów oraz administrację szkoły.
Używane technologie
O projekcie
Pony Academy prowadzi indywidualne lekcje jazdy konnej dla dzieci. Dla rodzica rezerwacja zaczyna się od zrozumienia doświadczenia: przebiegu lekcji, dostępnego sprzętu i sposobu, w jaki instruktor wspiera dziecko. Dla szkoły każda rezerwacja musi pasować do rzeczywistego harmonogramu instruktorów i koni.
Zbudowałem publiczną stronę oraz moduł rezerwacji Pony Academy na bazie mojego frameworka Aurum. Zakres łączy dedykowany frontend z dostępnością, rezerwacjami, integracją płatności, dostępem klientów i panelem administracyjnym.
Spokojna droga od poznania oferty do rezerwacji
Strona wyjaśnia przebieg pierwszej lekcji, zanim poprosi rodzica o decyzję. Łączy informacje o bezpieczeństwie, profil instruktorki, ofertę i odpowiedzi na częste pytania z wyraźnym przejściem do rezerwacji.
Proces rezerwacji dzieli złożony wybór na sześć kroków: oferta, termin, instruktor, koń, dane kontaktowe i płatność. Interfejs prezentuje dostępność przez API rezerwacji, zamiast wymagać od użytkownika porównywania osobnych kalendarzy. Obsługuje rezerwacje gościnne i konta klientów; założenie konta jest opcjonalne.
Frontend korzysta z Nuxt, Vue, TypeScript i Pinia. Rezerwacje, konta i integracje treści mają własne granice modułów, dzięki czemu komponenty prezentacyjne nie muszą zawierać reguł harmonogramu ani płatności.
Planowanie dwóch zasobów jednocześnie
Lekcja wymaga zarówno instruktora, jak i odpowiedniego konia. Wolny instruktor nie wystarcza, jeśli koń jest niedostępny, ma już rezerwację albo potrzebuje przerwy.
Zamodelowałem dostępność na podstawie harmonogramów instruktorów, blokad koni, istniejących rezerwacji, długości lekcji i reguł obciążenia konia. Kalendarz wylicza poprawne terminy z tych danych, zamiast utrzymywać drugi, potencjalnie niespójny zbiór dostępnych godzin.
Backend chroni również przed równoczesnymi żądaniami. Utworzenie tymczasowej blokady terminu i zmiana harmonogramu używają tych samych blokad zasobu i dnia w transakcji bazodanowej. Konflikty pozostają więc regułą biznesową egzekwowaną przez serwer także wtedy, gdy dwóch klientów lub administrator działa jednocześnie.
Domena harmonogramu nie zależy od Vue, HTTP, sterowników bazy danych ani dostawcy płatności. Te same reguły mogą obsługiwać publiczną rezerwację i operacje administracyjne.
Płatność jako cykl życia rezerwacji
Powrót z bramki płatniczej nie jest dowodem opłacenia lekcji. Ekran powrotu odczytuje stan rezerwacji i rozróżnia potwierdzenie, oczekiwanie oraz niepowodzenie.
| Sytuacja | Zachowanie systemu |
|---|---|
| Klient rozpoczyna płatność | Tymczasowo zablokuj wybrane zasoby i utwórz płatność z kluczem idempotencji. |
| Powiadomienie o płatności przychodzi ponownie | Zastosuj zmianę rezerwacji tylko raz przez transakcyjny rejestr zdarzeń. |
| Blokada terminu wygasa przed otrzymaniem płatności | Obsłuż spóźnioną płatność przez trwałe zlecenie zwrotu. |
| Klient wraca z bramki płatniczej | Odczytaj stan rezerwacji przed pokazaniem potwierdzenia. |
Przeglądarka może zachować sesję blokady rezerwacji, aby umożliwić odzyskanie procesu po odświeżeniu. Wygaśnięcie blokady, zdarzenia płatnicze i zasady anulowania pozostają pod kontrolą backendu. Powiadomienia i planowanie przypomnień są zapisywane razem ze zmianami rezerwacji, wiążąc dalszą pracę z zatwierdzonym stanem.
Aurum dla operacji, Aurora dla treści
Moduł Pony Academy integruje się z kontraktami Payments, Customers, Notifications, Storage i Translations w Aurum. Panel szkoły skupia oferty, konie, instruktorów, dostępność, blokady, rezerwacje i ustawienia powiadomień.
Tożsamość klienta należy do modułu Customers. Rezerwacja zachowuje własną historyczną kopię danych kontaktowych i oferty, a zweryfikowane konta mogą uzyskać dostęp do powiązanych rezerwacji. Dzięki temu zapis lekcji pozostaje zrozumiały także po późniejszej zmianie danych klienta lub oferty.
Aurora pozwala wizualnie edytować teksty i obrazy strony. Osadzona aplikacja wysyła intencje zmian do zaufanej aplikacji nadrzędnej, która autoryzuje i zapisuje edycję; publiczny frontend nie przechowuje tokenów administracyjnych. Opublikowane treści są pobierane podczas renderowania po stronie serwera, z określonymi wartościami domyślnymi na wypadek niedostępności usługi treści.
Projekt rozszerza Aurum poza strony nieruchomości: wspólne usługi platformy obsługują inną domenę biznesową, a publiczna strona zachowuje własną tożsamość.
Weryfikacja i efekt inżynierski
Kod rezerwacji zawiera testy konfliktów zasobów, równoczesnych blokad terminów i koni, uprawnień, idempotencji płatności oraz granicznych reguł harmonogramu. Scenariusze płatnicze mogą korzystać z lokalnego symulatora dostawcy, pozwalając sprawdzać ścieżki błędów bez rzeczywistych transakcji.
Publiczna strona i początek rezerwacji działają online. Efektem inżynierskim jest spójny produkt: rodzic poznaje ofertę i przechodzi przez uporządkowaną rezerwację, a implementacja daje szkole wspólny model zasobów, terminów, płatności i komunikacji.
Kluczową decyzją było pozostawienie reguł biznesowych w domenie rezerwacji, a wspólnych możliwości w Aurum. Dzięki temu frontend może się rozwijać bez powielania zasad chroniących harmonogram szkoły.