Обзор платформы
Sitora — платформа для сетей ресторанов, ведущая работу заведения от начала до конца: от гостя, сканирующего код за столом, до владельца, читающего цифры дня. Вся правда о процессах принадлежит одному бэкенду; каждый клиент отображает то, что бэкенд опубликовал, и никогда не выводит политику сам.
Продуктовые поверхности
Заголовок раздела «Продуктовые поверхности»| Поверхность | Аудитория | Что делает |
|---|---|---|
| Sitora | Гости | Приложение заказов: просмотр меню, заказ за столом, на доставку или самовывоз, отслеживание хода заказа. |
| Sitora Pro | Сотрудники | Рабочие места по ролям — официант, кассир, кухня, сервис-менеджер, менеджер склада, администратор филиала — каждое как отдельная панель управления. |
| Sitora Biz | Владельцы | Управление бизнесом: филиалы, сотрудники и роли, меню, финансы, подписки и регламентные действия вроде активации робототехники. |
| Sitora Console | Сотрудники Sitora | Внутренняя административная поверхность. |
| Robotics API | Поставщики роботов | Публичный версионированный HTTP-интерфейс для интеграции сертифицированных парков. |
Как части связаны между собой
Заголовок раздела «Как части связаны между собой»Ресторан — это бизнес; филиал — один физический адрес и операционная граница почти для всего: сотрудники работают внутри филиала, заказы принадлежат филиалу, запас считается по филиалу. Гости взаимодействуют с филиалом через посадки и заказы; сотрудники действуют через членства с ролями; владельцы управляют своими филиалами; сотрудники Sitora управляют платформой.
Робототехника следует той же форме: учётные данные робота привязаны к активации ровно одного филиала, и каждая задача подачи, которую видит робот, принадлежит этому филиалу.
Принципы проектирования
Заголовок раздела «Принципы проектирования»Sitora выпускает production-софт, а не прототипы. Конкретно, для каждой поверхности:
- Права, переходы состояний и допустимость вычисляются в бэкенде и публикуются
клиентам как явный
allowed_actions— если вы не видите действие, значит вы не можете его выполнить. - Значимые записи — события журнала, складские транзакции, оформленные заказы — неизменяемы. Исправления делаются компенсирующими записями, а не правками.
- Состояния сбоя (нет сети, устаревшие данные, конфликт, потеря доступа) спроектированы явно, а не обнаруживаются в бою.