01Operational Full Stack Platform

OPERATIONAL PRODUCT · FULL STACK · INFRASTRUCTURE

787 AirClub — Airport Transfer Operations Platform

Web/PWA-платформа для аэропортовых трансферов, где пассажир, водитель и операционная команда работают через связанные ролевые контуры и единый lifecycle заказа.

Краткое резюме проекта

Продукт
Airport transfer operations platform
Контуры
Passenger · Driver · Dispatcher · Admin
Роль
Product, Full Stack, data, integrations, delivery
Статус кейса
Public-safe · без production data

Business problem

Связать self-service и операционный контроль

Операции аэропортовых трансферов нельзя свести к одной форме заказа: нужны разные права, статусы, правила назначения, тарифные справочники, уведомления и ручной контроль исключений.

Задачи проекта
  • Дать пассажиру спокойный мобильный flow без внутренних операционных терминов.
  • Дать водителю доступ только к подходящим свободным и собственным заказам.
  • Сделать диспетчерские исключения и административные справочники наблюдаемыми.
  • Сохранить целостность lifecycle, финансовых снимков и аудита действий.

Решение

Что я построил

Web/PWA-платформа для аэропортовых трансферов, где пассажир, водитель и операционная команда работают через связанные ролевые контуры и единый lifecycle заказа.

Responsibility

Product, Full Stack и release engineering

Моя зона ответственности охватывает продуктовые сценарии, full stack реализацию и безопасную доставку изменений.

  1. 01

    Product model

    Роли, пользовательские flows, truthful states и границы MVP.

  2. 02

    Backend & data

    API, business rules, Prisma models, migrations и audit.

  3. 03

    Role interfaces

    Passenger, driver, operations и admin UX.

  4. 04

    Release engineering

    Tests, builds, smoke, deployment и recovery evidence.

15 · Публичные интерфейсы

Ролевые интерфейсы платформы

Кадры из явно помеченного demo-окружения. Все значения синтетические; production data не использовались.

04 · Privacy reviewed

Брендированный вход без введённого телефона или одноразового кода.
Пассажирский dashboard в явно помеченном демонстрационном аккаунте; значения синтетические.
Водительский empty state из demo-окружения без пассажиров и поездок.
Только верхний aggregate overview demo-аккаунта; идентификаторы и даты заказов исключены.

User roles

Четыре разделённых контура

Выберите узел · связи и практика

ОБЗОР СИСТЕМЫ

Разные роли. Общий жизненный цикл.

Пассажир, водитель и операционная команда работают с одним заказом через разные интерфейсы и права доступа.

Наведите или сфокусируйте для просмотра. Нажмите, чтобы закрепить выбор. Повторное нажатие или Escape — сброс.Нажмите на узел, чтобы посмотреть связи. Повторное нажатие сбрасывает выбор.

Ничего не выбрано

Заказ без внутренних операционных деталей

Пассажирский flow

Пассажир

  1. 01

    Направление

    В аэропорт или из аэропорта

  2. 02

    Адрес и точка

    Понятные пассажиру stops

  3. 03

    Время и состав

    Дата, время и пассажиры

  4. 04

    Создание заказа

    Серверная проверка и lifecycle

  5. 05

    Статус

    Ожидание, водитель найден, поездка

  6. 06

    Завершение

    История и уведомления

Доступность, assignment и поездка

Водительский flow

Водитель

  1. 01

    Доступность

    Рабочий статус и зона

  2. 02

    Доска заказов

    Только доступный scope

  3. 03

    Принять заказ

    Проверка назначения

  4. 04

    Подача

    Разрешённый transition

  5. 05

    В пути

    Операционный статус

  6. 06

    Завершить

    Финансовый snapshot и audit

Операции, справочники и исключения

Нормальные сценарии остаются self-service. Диспетчерский и административный контуры предназначены для видимости, настройки и исключений.

  • сводка проблемных и ожидающих заказов
  • назначение и освобождение водителя
  • управление ролями и доступом
  • зоны и аэропортовые точки
  • тарифные правила
  • финансы, отчёты и audit trail

Контролируемые переходы состояний

Пользовательские статусы выводятся из серверного состояния заказа, назначения водителя и audit events; интерфейс не создаёт декоративные состояния.

Lifecycle поездки

  1. 01

    Создан

    Заказ прошёл validation

  2. 02

    Ожидаем водителя

    Доступен подходящим водителям

  3. 03

    Водитель найден

    Assignment подтверждён

  4. 04

    Подача

    Водитель следует к пассажиру

  5. 05

    В поездке

    Активный маршрут

  6. 06

    Завершён

    Финальный статус и учёт

Ключевые решения

Разделённые роли, единые правила

  • Разные интерфейсы для пассажира, водителя и операционной команды.
  • Статусы определяются серверным lifecycle, а не интерфейсом.
  • Финансовые снимки и append-only ledger сохраняют историю поездки.

Infrastructure

Delivery и поддерживаемая эксплуатация

Production delivery разделяет frontend, backend и data responsibilities, проверяет release identity и сохраняет воспроизводимые recovery steps.

  • Next.js frontend и NestJS backend
  • PostgreSQL/Prisma migrations
  • Docker/Linux runtime
  • HTTPS/reverse proxy boundary
  • CI gates и immutable build identity
  • live/ready health checks
  • monitoring, backups и rollback documentation

Пять связанных слоёв платформы

Разделённые интерфейсы используют общие контракты application-слоя, единую реляционную модель и изолированные интеграционные адаптеры.

  1. 01

    Experience

    Passenger, driver, dispatcher и admin interfaces.

    • Next.js
    • React
    • responsive PWA
    • role-aware states
  2. 02

    Application

    Заказы, поездки, роли, назначения и переходы состояний.

    • NestJS
    • REST API
    • RBAC
    • validation
    • Socket.IO
  3. 03

    Data

    Реляционные модели, миграции, audit и finance ledger.

    • PostgreSQL
    • Prisma
    • migrations
    • transactions
    • indexes
  4. 04

    Integrations

    Уведомления, Telegram gateway и внешние provider boundaries.

    • webhooks
    • signed callbacks
    • realtime
    • provider adapters
  5. 05

    Delivery

    Сборка, проверки, release identity и эксплуатационные runbooks.

    • Docker
    • Linux
    • CI/CD
    • health checks
    • backups

Внутренние зоны, понятный пассажирский маршрут

Пассажир выбирает адрес и аэропортовую точку. Зоны остаются внутренними единицами matching, positioning и тарифной логики.

  • канонические зоны и airport points
  • направление и количество пассажиров
  • server-side price/quote contracts
  • admin-managed tariff rules
  • никаких неподтверждённых цен в интерфейсе
  • ручная корректировка только через контролируемый workflow

Снимки поездки и append-only ledger

Финансовый слой строится на зафиксированных снимках поездки и append-only ledger, а не на пересчёте истории в интерфейсе.

  • fare, service commission и driver income snapshots
  • personal/group/default commission source
  • manual adjustment с обязательной причиной
  • driver commission accrual/payment tracking
  • read-only reports и CSV
  • без acquiring, банковских выплат и налогового контура

Public boundary

Что намеренно остаётся закрытым

Публичный кейс показывает устройство продукта, но не открывает эксплуатационные данные или чувствительную конфигурацию.

  • только synthetic/demo screenshots
  • без реальных пассажиров, водителей и поездок
  • без балансов, invite/referral codes и номеров машин
  • без IP, доменов, credentials, logs и secrets
  • без неподтверждённых метрик или fleet claims
  • внутренние security/deployment детали обобщены