По онлайн-курсу OTUS «Software Architect»
С живой защитой проекта вы можете ознакомиться в этом видео:
Описание проблемы
Исходная задача
A large hotel reservation company wants to build the next generation hotel reservation and management system specifically tailored to high-end resorts and spas where guests can view and reserve specific rooms.
- Users: Guests (hundreds), hotel staff (less than 20)
- Requirements:
- Registration can be made via web, mobile, phone call, or walk-in.
- Guests have the ability to either book a type of room (standard, deluxe, or suite) or choose a specific room to stay in by viewing pictures of each room and its location in the hotel.
- The system must be able to maintain room status (booked, available, ready to clean, etc.) as well as when the room will be needed next.
- It must also have state-of-the-art housekeeping management functionality so that cleaning and maintenance staff can be directed to various rooms based on priority and reservation need using proprietary devices supplied by the reservation company attached to the cleaning carts.
- Standard reservation functionality (e.g., payments, registration info, etc.) will be done by leveraging the existing reservations system.
- The system will be web-based and hosted by the reservation company.
- Additional Context:
- ‘Peak season is quickly approaching, so the system must be ready quickly or we have to wait until next year!’
- Company is also investing heavily in cutting edge technology like smart room locks that open via a cell phone
- Only interested in the high-end market
- Sales people have tremendous clout in the organization; people often scramble to make their promises true
Контекст
Заказчик — крупная компания, с сильным отделом продаж, инвестирующая в такие передовых технологии как интернет вещей, связанный с отелями.
Основной бизнес заказчика — это бронирование номеров в отелях.
Компания уже эксплуатирует систему бронирования отелей, покрывающая стандартные функции, например: работа с оплатой, предоставление информации по регистрациям.
Заказчик намерен построить систему бронирования и управления отелями следующего поколения, ориентированную на элитные курорты и СПА. Будущие гости отелей перед бронированием могут визуально ознакомиться с номерным фондом и расположением отдельных номеров.
У заказчика должна быть полная картина о занятости и статусе каждого номера.
Система должна поддержать автоматизацию управления уборкой в номерном фонде.
Будущая система должна быть с веб-интерфейсом и размещаться у заказчика.
Проект должен быть запущен в сжатые сроки, так как близок сезон активного использования системы.
В пик нагрузки система должна беспроблемно обслуживать сотни гостей и не более 20 сотрудников отеля для каждого отеля, подключенного к системе.
Ожидается, что система позволит осуществлять регистрацию онлайн через веб, смартфон, заявки по телефону и без предварительной записи.
Бизнес-цели
Компания намерена:
- в сжатые сроки увеличить продажи услуг за счёт охвата рынка элитных курортов и спа, а также посредством инвестируемых передовых технологий,
- повысить эффективность существующего функционала системы в части своевременного отслеживания ЖЦ всего продаваемого номерного фонда,
- увеличить воронку продажи устройств для эффективного управления персоналом по уборке номеров, через добавление функций автоматизации процессов уборкой номерного фонда,
- увеличить продажи умных устройств, например «умные» замки для номеров.
Архитектурные драйверы
Исходя из задачи и бизнес-целей основными драйверами являются:
- текущая система резервирования отелей не отвечает требованиям к функционалу для сотрудничества с элитными курортами и спа,
- отсутствует синергия между продажами услуг резервирования и передовыми разработками, в которые компания активно инвестирует (например, устройства для автоматизации управления уборкой и «умные» замки, управляемые через смартфон).
Ограничения технологические и бизнесовые
- регистрация в системе может быть осуществлена через веб, смартфон и телефонный звонок,
- система резервирования уже существует, и к самой системе претензий нет,
- система должна иметь веб-интерфейс,
- система должна размещаться у заказчика (on premise),
- срок запуска системы ограничен 1 годом,
- система должна иметь опцию использования сопряжения с устройствами для персонала отвечающего за уборку номерного фонда и смартфонами гостей.
Описание требований
Стейкхолдеры
SH1: Гости отелей (доступность, производительность, масштабируемость, отказоустойчивость, удобство использования):
- с помощью системы должны быть способны найти подходящий для себя номер, визуально оценить, зарезервировать и оплатить его удобным для себя способом
- опционально, в случае если отель оборудован умными устройствами от заказчика, используют собственный смартфон с предустановленным приложением управлять доступными, в номерах и отеле, «умными» устройствами.
SH2: Штатные сотрудники отеля (доступность, производительность, масштабируемость, отказоустойчивость, безопасность):
- должны быть способны поддерживать в актуальном состоянии ЖЦ номерного фонда,
- должны быть способны поддерживать, в актуальном состоянии визуальную и не визуальную информацию о номерах отеля,
- должны быть способны бронировать номера.
SH3: Служба уборки в номерах (доступность, масштабируемость, отказоустойчивость, безопасность):
- опционально, при условии, что служба уборки номеров снабжена специальными устройствами, привязанными к тележкам для уборки, должны быть способны своевременно, в соответствии с приоритетами выполнять задания на уборку
Пользовательские сценарии
UC1: Работа с информации об отеле:
- штатный сотрудник, управляет состоянием номерного фонда доступных отелей (SH2),
- штатный сотрудник, управляет визуальной и не визуальной информацией о номерах отеля (SH2),
- штатный сотрудник, производит поиск свободных номеров в соответствии с условиями гостя (SH2)
- штатный сотрудник, осуществляет бронь/отмену брони по телефону, по запросу на стойке регистрации (SH2)
UC2: Резервирование номеров:
- гость, производит поиск свободных номеров в соответствии с критериями отбор (SH1)
- гость, бронирует/отменяет бронь через веб интерфейс (SH1)
- гость, бронирует/отменяет бронь через смартфон (SH1)
- гость, бронирует/отменяет бронь через заявку по телефону (SH1)
UC3: Уборка в номере:
- служба уборки в номерах получает задачу на уборку в номере (SH3),
- сотрудник службы уборки берёт задачу в работу (SH3),
- сотрудник службы уборки начинает выполнение задачи (SH3)
- сотрудник службы уборки завершает задачу по уборке (SH3)
- сотрудник службы уборки уведомляет о проблемах (SH3)
UC4: Управление устройствами номера:
- гость, штатный сотрудник, специалист службы уборки в номерах, открывает/закрывает номер, с помощью собственного смартфона (SH1)
Сценарии для атрибутов качества
QA1: доступность (UC1, UC2, UC3, UC4)
- управление состояние номерного фонда, должно иметь максимальный уровень доступности, так как это может критично сказаться на корректном резервировании номерного фонда,
- недоступность системы при публикации актуальной визуальной/ не визуальной информации о номерах отеля может стать причиной рекламаций со стороны требовательных гостей,
- несвоевременное подтверждение заявок может сказаться на продажах номерного фонда,
- гости элитных курортов и спа не должны сталкиваться с какими-либо проблемами доступа к системе, при поиске номеров или во время выбора номеров и бронирования,
- недоступность системы, для службы уборки в номерах, напрямую влияет на качества и своевременность сервиса,
- сервисы управления умными устройствами в номере должно иметь высокий уровень доступности для гостей.
Полагаем что, система относится к уровню Business critical системам.
QA2: производительность (UC1, UC2, UC3)
- реакция системы на управление номерным фондом, в пик нагрузки, для отеля, не должна превышать 3 с (при условии замеров на границе publiс-DMZ),
- реакция системы на доставку единицы визуальной информации о номерном фонде, для отеля, не должна превышать 8 сек (при условии замеров на границе publiс-DMZ),
- реакция система на бронь по телефону номера/номеров не должна превышать 3 с (при условии замеров на границе publiс-DMZ),
- реакция система на бронь по веб номера/номеров, не должна превышать 3 с (при условии замеров на границе publiс-DMZ),
- реакция система на бронь через смартфон, не должна превышать 3 с (при условии замеров на границе publiс-DMZ и соблюдения нефункциональных требований к мобильному устройству),
- реакция системы на поиск подходящего отеля и номера/номеров не должна превышать 5 с (при условии замеров на границе publiс-DMZ).
QA3: масштабируемость (UC1, UC2, UC3, UC4)
- максимальное число штатных сотрудников отеля в смену 20,
- максимальное число гостей отеля 1000.
QA4: отказоустойчивость (UC1, UC2, UC3, UC4)
- штатные сотрудники должны беспрепятственно и любых проблем поддерживать в актуальном состоянии номерной фонд. Любые коллизии, связанные с резервированием, могут сказаться на рейтингах отеля или курорта,
- для гостей, система должна работать стабильно. Любая поломка/сбой может привести к потере гостей,
- любые сбои в службе уборки номеров могут повлиять на своевременные приём гостей и смещении в графике уборки номерного фонда,
- поломка/сбой «умного» замка может привести к снижению рейтинга отеля.
QA5: удобство использования (UC2, UC4)
- для всех случаев делается ставка, на удобство клиентов при резервировании номеров и управлением умными замками
QA6: безопасность (UC1, UC3, UC4)
- штатные сотрудники работают с персональными данными гостей, система должна быть защищена от НСД,
- доступ к данным службы уборки номеров должен иметь авторизованным, в соответствии с графиком дежурства персонала,
- умные замки должны управляться только авторизованными гостями и только на время пребывания в отеле
QA7: расширяемость (UC1, UC2, UC3, UC4)
- число отелей, подключаемых к системе, может увеличиваться,
- функционал для сотрудников может расширяться,
- функционал для гостей может расширяться,
- число умных устройств, которыми могут управлять гости отеля может быть расширен.
Ограничения
- CON1: для гостей, система должна поддерживать доступ к резервированию через вэб или смартфон,
- CON2: вэб интерфейс должен быть совместим с крайней версией браузера Google Chrome (110.0.5481.*),
- CON3: вэб интерфейс должен беспроблемно работать в разрешениями экранов 1366×768 и 1920×1080,
- CON4: мобильное приложение должно работать под управлением, минимум, начиная с 12 версии ОС Android,
- CON5: мобильное приложение должно работать под управлением, минимум, начиная с 14 версии ОС iOS,
- CON6: новая система должна быть размещена в ЦОД-ах заказчика,
- CON7: новая система должна «развитием» существующую систему резервирования и дополнять её.
Предположения
- ASM1: эксплуатируемая система имеет программные интерфейсы для работы с регистрационными действиями и приёмом оплаты,
- ASM2: эксплуатируемая система имеет собственные сервисы аутентификации и авторизации (включая one time password),
- ASM3: эксплуатируемая система имеет АПИ для интеграции с внешними системами (синхрон/асинхрон)
- ASM4: заказчик является совладельцем компании по производству умных замков,
- ASM5: все отели, оборудованные умными замками, рассчитывают на наличие у клиентов собственного смартфона. При отсутствии смартфона у клиента, отель имеет резерв «умных» ключей, которые клиент может взять во временное пользование. Но это вне границ текущей задачи,
- ASM6: первичной визуализации номеров всех отелей уже была проведена, банк изображений в необходимом формате сделана и наполнение системы было произведено,
Описание решения
Контекстная диаграмма
Диаграмма контейнеров
Рисунок. Схема высокоуровневой архитектуры решения.
Как показано на схеме, выбрана сервис-ориентированная архитектура, и, в частности, микросервисный подход см. «Лог архитектурных решений», ADR1.
Решение покрывает 2 основных домена:
- домен осуществления поиска по номерному фонду,
- домен управления номерным фондом.
Решение предполагает создание 2 мультиплатформенных мобильных приложений на базе Flutter, см. «Лог архитектурных решений», ADR4.
Диаграммы последовательности для пользовательских сценариев
Порядок загрузки визуальной информации о номере (UC1)
Предполагаем, что актуальные панорамы номеров уже сделаны см. «Лог архитектурных решений», ADR2 и ADR3.
Рисунок. Диаграмма последовательности для случая публикации визуальных данных о номере.
Порядок поиска номера и загрузки визуальных данных (UC1, UC2)
Рисунок. Диаграмма последовательности для случая поиска номера с выводом визуальных данных
Порядок бронирования номера (UC1, UC2)
Рисунок. Диаграмма последовательности для случая бронирования номера штатным сотрудником
Порядок применения правил доступа для «умного» замка (UC1)
Рисунок. Диаграмма последовательности для случая публикации правил доступа.
Порядок открытия/закрытия «умного» замка (UC2, UC3)
Рисунок. Диаграмма последовательности для случая
Порядок получения задания «уборщиком» (UC3)
Рисунок. Диаграмма последовательности для случая
Диаграмма развертывания
Рисунок. Диаграмма развёртывания
Лог архитектурных решений (ADL, ADR)
ADR1: Выбор общей архитектуры решения
Статус
Предложение
Контекст
Текущее решение не отвечает требованиям системы следующего поколения, так как аудитория элитных курортов и отелей требовательная и любой отказ системы или длительные ответы могут сказаться на спросе и отзывах.
Нагрузка на системы резервирования могут иметь высокую амплитуду нагрузки в зависимости от сезона и «маркетинговых мероприятий».
Решение
Предлагаю построить распределённую систему, разделённую на 2 домена:
- поиск и предоставление информации о доступном номерном фонде,
который должен будет иметь высокую доступность, производительность и отказоустойчивость,
- управление номерным фондом, не должно оказывать влияние на архитектурные атрибуты качества поиска номеров и требует дополнительных мер безопасности.
Для решения задачи следует использовать микросервисный архитектурный стиль.
Последствия
- каждый домен должен обладать собственным, автономным хранилищем данных и набором сервисов,
- для хранения визуальной информации данных о номерном фонде, вероятно понадобится отдельный способ хранения данных
ADR2: Определение формата визуализации номерного фонда
Статус
Предложение
Контекст
Для удобства гостей, система должна предоставлять пользователю возможность оценить номер визуально, перед тем как принять решение.
Решение
Предлагаю использовать уже популярную технологию визуализации номерного фонда, известную как VR 360.
Технология позволяет с помощью специализированной камеры создать панорамную съёмку в уже привычных графических форматах TIFF, JPEG, PNG и т.п.
Для отображения созданной панорамы могут использоваться широкий спектр библиотек как для мобильного приложения, так и для клиентских библиотек ReactJS или Angular.
Последствия
- для достаточной доступности визуализации номером для клиентов, необходимо использовать content delivery network. При этому необходимо организовать своевременную публикацию панорам.
- требуется организовать отдельное хранилище графических изображений.
ADR3: Определение места хранения для визуального представления номерного фонда
Статус
Предложение
Контекст
Для организации банка изображений номерного фонда необходимо организовать отдельное хранилище.
Решение
Использовать объектное хранилище MinIO.
Данный продукт позволяет организовать высокодоступное и отказоустойчивое решение, позволяющие масштабировать хранение графических изображений.
Последствия
- покупка коммерческой лицензии на MinIO, так как бесплатный вариант распространяется под лицензией AGPL 3.0.
ADR4: Определение архитектуры решения для работы на мобильных устройствах.
Статус
Предложение
Контекст
Система предполагает управления умными «замками».
Пользователями «умных» замков являются не только гости, но и штатные сотрудники отеля, а также специалисты службы уборки в номерах.
Заказчику хотелось бы иметь универсальные мобильные приложения, для каждой группы пользователей.
Решение
Целесообразно разработать и реализовать 2 приложения:
- гостевое, с публичным доступом к АПИ поиска и бронирования номеров,
- для внутреннего использования, с закрытым АПИ для штатных сотрудников и службы уборки в номерах.
Для максимального охвата гостевой аудитории и возможности масштабирования решения на новые отели, необходимо чтобы с одной стороны приложение было мультиплатформенным, с другой стороны было бы простым в реализации и развитии.
Помимо вышеописанного, приложение потребует использование нативных возможностей мобильных устройств, таких как сопряжение с «умными» замками отеля с использованием Bluetooth Low Energy стандарта.
В качестве решения предлагаю использовать Flutter, см. https://flutter.dev/ совместно с SDK производителя/поставщика «умных» замков.
Все мобильное приложения, предварительно, должны состоять из 2х модулей:
- модуль работы с АПИ системы,
- модуль управления «умным» замком.
Последствия
- потребуется команда для разработки, развития и поддержки мобильных приложений,
- потребуется найти способ и место публикации мобильных приложений,
- провести R&D работы по интеграции МП с замками.
ADR5: Определение решения для управления «умными» замками
Статус
Предложение
Контекст
Как было описано в постановке задачи, компания инвестирует в развитие IoT технологий. Для получения синергетического эффекта от вложений, при внедрении новой системы требуется учесть в архитектуре системы использование «умных замков», которыми могут быть оборудованы элитные курорты и отели.
Решение
Предлагаю, в качестве решения использовать подход ACaaS (access control as service) для «умных устройств». Это вариация технологии «программное обеспечение как услуга» (SaaS). Другими словами размещена, так же, в облаке. В тоже время, все оборудование для контроля доступа остается на месте, а программное обеспечение и серверы размещаются в дата-центрах.
Рисунок. Высокоуровневая схема решения.
Основные тезисы:
- партнёрская компания вместе с «умными замками», обеспечивает доступ к облачному решению контроля доступа,
- на основе специализированного SDK мобильное приложение гостей отеля, штатных сотрудников и службы уборки в номерах интегрируется с облаком провайдера, либо напрямую/либо опосредованно через разрабатываемую систему резервирования. Интеграция необходима прежде всего для ротации кодов авторизации «умных» замков и централизованного аудита всех умных устройств,
- пока, «абстрактное», мобильное приложение должно иметь функционал аутентификации и отправки авторизованных команд открытия/закрытия,
- мобильное приложение взаимодействует с «умными» замками по протоколу BLE (Bluetooth Low Energy),
- все «умные замки» обладают встроенным безопасным BLE сервисом и локальным хранилищем правил доступа, которое может управляться напрямую из системы резервирования,
- для обеспечения безопасности, должно быть разработано МП: для гостя, штатного сотрудника и службы уборки в номерах (получение временного доступа к замку, открытие/закрытие).
Рисунок. Топология сегментов решения применительно к проработке.
Последствие
- потребует учесть в новой системе, при регистрации/освобождении номеров, централизованное управление правилами и синхронизацию правил доступа с «замками»,
- понадобится разработать отдельные, мультиплатформенные мобильные приложения и осуществлять их поддержку,
- для каждого отеля необходимо организовать сеть умных устройств, подключенную по VPN с системой резервирования и управления.
Автор — Евгений Яцура.
Хотите знать больше о проектировании архитектуры программных приложений? Добро пожаловать на курс «Software architect» в Otus!
