Wstęp
W przypadku tworzenia aplikacji hotelowych, sukces zależy nie tylko od zawartych w nich funkcji, ale także od stworzenia skalowalnego, adaptacyjnego i niezawodnego oprogramowania. Każdy obiekt hotelowy będzie na przestrzeni lat charakteryzował się różnym wykorzystaniem i natężeniem ruchu ze strony gości, a dodanie funkcji mobilnych będzie wymagało solidnych podstaw zarówno w architekturze zaplecza, jak i modelu danych.
W Appricotsoft z powodzeniem zapewniamy klientom z branży hotelarskiej wsparcie niezbędne do stawienia czoła tym wyzwaniom, łącząc solidną architekturę z praktyczną implementacją aplikacji hotelowych. W poniższym artykule omówimy każdą podstawową decyzję techniczną, którą należy podjąć w całym procesie rozwoju aplikacji wspierającej gości w hotelu – od zarządzania tożsamością gości po zarządzanie wieloma obiektami – oraz nasze podejście do każdej z nich, aby zminimalizować związane z nimi ryzyko, jednocześnie podnosząc ich niezawodność.
Znaczenie architektury dla gościnności
Podczas opracowywania aplikacji dla gości hotelowych użytkownik końcowy może nigdy nie zetknąć się z zapleczem aplikacji. Odczuje jednak konsekwencje decyzji architektonicznych podjętych na wczesnym etapie cyklu rozwoju aplikacji, takie jak dłuższy czas reakcji, niezgodność informacji o rezerwacji lub nieudane żądania użytkownika.
Dobra architektura umożliwia:
- Bezproblemowy proces rezerwacji i odprawy
- Aby ułatwić zarządzanie wieloma nieruchomościami bez duplikowania informacji w zapleczu
- Zarządzanie tożsamościami i preferencjami gości podczas wielu pobytów w hotelu
- Aby zapewnić prawidłowe śledzenie zgłoszeń serwisowych, co umożliwi dokładne rozliczenie
- Aby zapewnić rozliczalność poprzez udostępnianie historii żądań serwisowych, bezpieczeństwa, idempotencji i śladów audytu zgodnie z obowiązującymi przepisami
Na początek omówmy podstawy dobrej architektury aplikacji hotelowej.
Monolit, mikrousługi czy modułowy monolit: który wybrać dla swojego zaplecza?
Istnieje wiele różnych architektur zaplecza. Jak więc zdecydować, która jest najlepsza?
Poniższa lista przedstawia nasze przemyślenia na temat tych trzech opcji:
- Monolit
Zazwyczaj architektura monolityczna jest najłatwiejsza do opracowania; idealnie sprawdza się w mniejszych, prostszych hotelach i produktach MVP (minimalnie opłacalnych). Jednak gdy obiekty zaczynają się rozrastać, a logika stojąca za każdym obszarem zaczyna się przenikać, skalowanie staje się znacznie bardziej skomplikowane.
- Mikrousługi
Mikrousługi świetnie sprawdzają się w przypadku rozwoju większych marek lub platform hotelowych. Jeśli korzystasz z wielu zespołów – na przykład jeden odpowiada za rezerwacje, drugi za obsługę gości, a trzeci za płatności – ta opcja jest idealna. Musisz jednak wdrożyć solidne procesy DevOps i zapewnić obserwowalność.
- Modułowy monolit
Uważamy, że modułowy monolit to dobra strategia od samego początku. Wyraźne linie podziału między poszczególnymi modułami (rezerwacja, gość, obsługa) dają możliwość stworzenia pojedynczej, łatwej do wdrożenia jednostki z wyraźnymi granicami dla potrzeb konserwacji.
Często pytacie nas, jaką architekturę referencyjną moglibyśmy polecić. Sugerujemy, aby w Appricotsoft zacząć od modułowego monolitu, wykorzystując naszą metodę dostarczania Unison, w której jakość i przewidywalność są częścią wszystkich warstw od samego początku procesu rozwoju.
Tworzenie systemów dla wielu właściwości
System hotelowy zaprojektowany dla jednego lub dwóch hoteli zazwyczaj opiera się na podstawowych założeniach dotyczących obiektu (lokalizacji), rodzaju zasobów i sposobu działania danego obiektu. W przypadku zarządzania wieloma hotelami lub obiektami franczyzowymi założenia te szybko stają się bardziej skomplikowane.
Najlepsze praktyki / zasady projektowania:
- Jawne modelowanie podmiotów hotelowych (obiektów hotelowych, marek hotelowych, regionów hotelowych itp.)
- Konfiguracja zakresowa (podatek, typ pokoju, dostępność usługi)
- Wyodrębnij zasoby według obiektu hotelowego, ale zezwól na wspólne profile gości/użytkowników we wszystkich obiektach.
- Zdefiniuj role i uprawnienia na poziomie obiektu hotelowego.
Projekt ten umożliwi rozwój lub ekspansję franczyzową, niezależnie od tego, czy będzie to 2 czy 200 hoteli.
Tworzenie tożsamości i profili gości
Tożsamość gościa to coś więcej niż tylko adres e-mail i imię; tożsamość gościa jest podstawowym elementem personalizacji, programów lojalnościowych i spójnej obsługi.
Elementy modelu danych:
- Podstawowy identyfikator (adres e-mail, numer telefonu, tożsamość federacyjna (Google, Apple))
- Historia wizyt (historia rezerwacji, historia opinii, historia preferencji)
- (Historia preferencji gościa) Typ pokoju, Język, Alergie, Rodzaj poduszki
- Powiązane konto (rozliczenia firmowe, członkowie rodziny itp.)
Zawsze projektuj swój model danych gości, mając na uwadze prywatność i bezpieczeństwo gości. Stosuj minimalizację danych i szyfruj poufne informacje. Dodatkowe punkty za integrację logowania jednokrotnego (SSO) z systemem PMS lub innym systemem CRM.
Cykl życia rezerwacji
Rezerwacje są podstawą działalności hotelu i dlatego stanowią jeden z najważniejszych aspektów aplikacji hotelowej
Najważniejsze stany, które należy utrzymywać w systemie rezerwacji, to:
- Oczekujące → Potwierdzone → Zameldowane → Wymeldowane → Anulowane
- Status płatności: Oczekująca, Częściowo zapłacona, Całkowicie zapłacona, Zwrócona
- Przydział pomieszczeń: Przydział wstępny lub przydział dynamiczny
- Usługi powiązane: transfer, spa, wyżywienie itp.
Rezerwacje muszą być idempotentne. Innymi słowy, jeśli żądanie mobilne zostanie wysłane więcej niż raz (z powodu problemów z łącznością lub innych problemów), nie powinno to skutkować utworzeniem duplikatu rezerwacji (podwójnej rezerwacji) ani obciążeniem gościa więcej niż dwukrotnie.
Użyj tokenów, znaczników czasu lub unikalnych identyfikatorów żądań klienta, aby wyeliminować duplikaty spowodowane ponownymi próbami na urządzeniach mobilnych i/lub zapleczu.
Cykl życia prośby (od ręcznika do taksówki)
Obsługa pokoju, dodatkowe ręczniki i transfery to przykłady próśb, które mogą mieć wpływ na zadowolenie gościa i wszystkie wymagają śledzenia, widoczności i rozliczania przez cały cykl życia danej prośby, zarówno ze strony gościa, jak i personelu hotelu.
Projektując Asystenta ds. żądań, należy wziąć pod uwagę następujące kwestie:
- Status żądania: Żądane, Zaakceptowane, W trakcie realizacji, Zakończone, Anulowane
- Znak czasu i pracownik obsługujący żądanie w momencie każdej zmiany statusu.
- Możliwość przekazania opinii przez gościa po zrealizowaniu prośby.
- Możliwość otrzymywania powiadomień w czasie rzeczywistym przez personel hotelu za pośrednictwem integracji lub pulpitu nawigacyjnego.
Projektując ten przepływ, zazwyczaj uwzględniamy w systemie ścieżki audytu, dzięki czemu zarówno pracownicy hotelu, jak i goście widzą, co się wydarzyło, a także datę i godzinę tego zdarzenia, tworząc w ten sposób mierzalne dane dotyczące jakości usług.
Znaczenie idempotencji i śladów audytu
W technologii hotelowej zdarzają się sytuacje, w których ten sam przycisk może zostać naciśnięty wielokrotnie z powodu słabego połączenia Wi-Fi, pośpiechu podczas odprawy lub po prostu dlatego, że klient jest zdezorientowany. Dlatego, chociaż idempotentność może być uznawana za zaletę w niektórych systemach, my traktujemy ją jako wymóg.
Aby wykonać jakąkolwiek akcję API, która dokonuje wpisu do Twojej bazy danych, musi zostać wykonane następujące działanie:
- Akceptuje unikalny idempotentny klucz.
- Można bezpiecznie powtórzyć zabieg bez skutków ubocznych.
- Zwraca deterministyczne odpowiedzi.
Podobnie istotne są ślady audytu; w rzeczywistości również je zachowujemy.
- Kto dokonał tej zmiany?
- Kiedy to się stało?
- Co zmieniło się od „przed” do „po”?
- Z jakiego urządzenia lub systemu?
Ślady audytu są przydatne w różnych celach: od debugowania problemów, przez przestrzeganie przepisów, po pomoc Gościom w zakresie próśb o wsparcie.
Jak realizujemy to w Appricotsoft
W Appricotsoft wykorzystujemy nasz autorski framework Unison, dzięki czemu wszystko, co robimy, jest jasne, przewidywalne i skalowalne od samego początku. Od samego początku projektu współpracujemy z zespołem projektowym naszego Klienta, aby wypracować konsensus w kluczowych decyzjach i przeprowadzać cotygodniowe demonstracje, które nasi Klienci mogą odczuć. Każdy projekt będzie obejmował:
- Opis projektu i dokładny rejestr zadań.
- Jasno zdefiniowane kryteria akceptacji dla wszystkich funkcji.
- Rejestr ryzyka umożliwiający śledzenie wszelkich ryzyk architektonicznych i integracyjnych.
- Cykl demonstracji na żywo, dzięki któremu możemy regularnie oceniać nasze postępy.
- Bramki jakości: przegląd kodu, testowanie, zapewnienie jakości, dokumentacja i gotowość do wdrożenia.
Chcesz zobaczyć, jak to wygląda w praktyce? Sprawdź nasz wpis na Wzorce UX aplikacji hotelowych lub jak sobie radzimy MVP zostanie wdrożony na platformach hotelowych.
Podsumowanie
Struktura i model danych aplikacji Twojego hotelu mogą sprzyjać rozwojowi lub go utrudniać. Wybór skalowalnej struktury, prawidłowe zdefiniowanie podstawowych obiektów w aplikacji oraz wdrożenie najlepszych praktyk, takich jak idempotentność i rejestrowanie audytów, są kluczowe dla stworzenia rozszerzalnej platformy, dzięki której Twoja aplikacja będzie przyciągać prawdziwych i stałych klientów.
Czy zechcesz nawiązać z nami współpracę, aby przyspieszyć rozwój Twojej aplikacji hotelowej?
👉 Zacznij budować już dziś! Zapytaj o wycenę opracowania aplikacji hotelowej, i zaprojektujmy dziś solidną architekturę!
