Одна карточка гостя на всё проживание

Большинство hospitality-стеков — набор инструментов, которым случилось делить одно здание. Бронь живёт в PMS. Ресторан ведёт свои тикеты. Room service — звонок, который может так и не стать строкой folio. К утру night audit превращается в спор.

Решается это не очередной интеграцией. Решение скучное: один гость, одно проживание, один folio. Всё остальное — представление этой записи.

Что должно быть общим

В StayBoard сложность не в экранах. Она в том, о чём продукту вообще позволено расходиться. Номера, тарифы и гости раздваиваться не могут. Кухонные тикеты могут — это события. Строки folio не могут — это деньги.

• Бронь создаёт проживание. Check-in не изобретает второго гостя.
• Заказ room service падает в тот же folio, который уже открыт на ресепшене.
• Статус housekeeping — свойство номера, а не сообщение в чате.
• Night audit закрывает операционный день, а не выгрузку в таблицу.

API следует за записью, а не за экраном

Если гостевой портал может заказать завтрак, он не должен ходить в отдельную «базу заказов». Он должен создать начисление на проживание, которое PMS уже знает. Кухонный дисплей может быть отдельным сервисом. Деньги — нет.

Поэтому я беру Spring Boot-сервисы с явными границами и общей моделью данных, а не кучу микросервисов, у каждого из которых своя копия гостя. Распределённость стоит дорого. Платить за неё стоит тогда, когда этого требует нагрузка, — а не потому что схема выглядела эффектно.

Когда это работает, становится тихо. Кухня видит тикет. В folio начисление уже есть. Гостю не понадобился новый аккаунт. Именно по такой архитектуре я и хочу, чтобы меня оценивали.