Shablon_itogovoi_774_prezentatsii_Professia_Sistemnyi_774_analitik

1.

Итоговый проект по программе
«Профессия: Системный аналитик»
Вальтер Дарья Евгеньевна
Посмашная Полина Александровна

2.

Описание проекта
Название проекта: Проектирование
сервиса онлайн-записи в клиники
Наш сервис – единая платформа,
которая связывает пациентов и
медицинские клиники. Он решает
проблему неудобной записи
через регистратуру. Система
позволяет автоматизировать
процесс поиска свободных
слотов, бронирования и
управления записями.

3.

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

4.

Описание проекта
Мы выделили 6 ключевых сценариев. Среди которых:
1. Поиск и просмотр слотов.
2. Создание записи.
3. Просмотр информации о записи.
4. Отмена записи.
5. Администрирование услуг (для сотрудников клиники).
6. Управление расписанием работы клиники.

5.

Часть 1. Сбор требований
Функциональные
требования системы
1. Управление клиниками и
расписанием
2. Управление медицинскими
услугами
3. Поиск и просмотр доступных
слотов
4. Создание и управление записью
5. Отмена записи
Нефункциональные
требования системы
1. Как пользователь я хочу, чтобы страница с доступными
слотами загружалась быстро (даже когда тысяч других
пользователей заходят на нее одновременно), чтобы я не
раздражался и не покинул сайт из-за долгой загрузки.
2. Как пользователь я хочу, чтобы запись
подтверждалась мгновенно (даже если 500 человек
пытаются записаться на последний свободный слот
одновременно), чтобы я точно знал, что место мое, и не
возникло ситуации «двойной записи».
3. Как владелец платформы я хочу, чтобы сервис
был доступен практически всегда (за исключением
плановых работ, о которых объявляется заранее), чтобы
клиники не теряли деньги, а пользователи могли
записаться в любое время суток.
4. Как администратор клиники я хочу, чтобы данные о
записях не терялись (даже если один из серверов базы
данных внезапно выйдет из строя), чтобы мне не
пришлось вручную восстанавливать расписание.

6.

Часть 2. Архитектура
Context diagram

7.

Часть 2. Архитектура
Context diagram
Пользователи
Пациент: поиск клиник/врачей/услуг, просмотр слотов, создание и отмена записей.
Администратор клиники: управление расписанием, услугами, ценами, просмотр записей.
Границы системы
Платформа онлайн-записи: агрегация данных клиник, интерфейсы бронирования,
гарантия сохранности.
Внешние системы
МИС Клиник: синхронизация расписаний и данных о записях.
Платежный шлюз: оплата услуг при бронировании.
Сервис уведомлений: отправка подтверждений и напоминаний (SMS/Email/Push).
Взаимодействия
Пациент ↔ Платформа (слоты, создание/отмена).
Администратор ↔ Платформа (управление расписанием и услугами).
Платформа ↔ МИС (синхронизация).
Платформа → Платежный шлюз (инициация оплаты).
Платформа → Уведомления → Пациент.

8.

Часть 2. Архитектура
Container diagram

9.

Часть 2. Архитектура
Container diagram
Набор контейнеров и их ответственность
Вся система разделена на независимые контейнеры для обеспечения масштабируемости,
отказоустойчивости и изоляции бизнес-логики:
Web / Mobile App – клиентский интерфейс для пациентов и администраторов:
отображение данных, ввод, первичная валидация.
API Gateway – единая точка входа: маршрутизация, JWT-аутентификация, защита от
перегрузок.
Служба клиник и услуг – справочные данные: клиники, врачи, услуги, направления.
Служба расписания – высоконагруженный сервис: поиск и выдача свободных слотов,
пагинация, обработка сетки расписания из МИС.
Служба записи – ядро транзакционной логики: создание, подтверждение, отмена
бронирований, защита от двойной записи на один слот.
Служба интеграции с МИС – адаптер для связи с внутренними системами клиник,
трансляция событий в протоколы МИС.
Служба уведомлений – асинхронная отправка email/SMS при смене статуса записи.
Брокер сообщений – асинхронный обмен событиями между сервисами для слабой
связанности.

10.

Часть 2. Архитектура
Container diagram
Взаимодействия и потоки данных
Взаимодействие между контейнерами делится на синхронное и асинхронное.
Синхронные вызовы:
1. Поиск слотов: Web/Mobile App → API Gateway → Slot Service.
2. Запрос информации о записи: Web/Mobile App → API Gateway → Booking Service.
3. Инициация записи/отмены: Web/Mobile App → API Gateway → Booking Service.
Асинхронные события:
Сценарий «Создание записи»:
Booking Service проверяет слот и публикует событие BookingCreated в Брокер сообщений.
Кто слушает (подписчики):
Slot Service перехватывает событие и отмечает слот как занятый в своей базе данных и кэше.
Integration Gateway получает событие и отправляет запрос во внешнюю МИС клиники для блокировки
слота на стороне клиники.
Notification Service реагирует на событие и отправляет пациенту SMS/Email с подтверждением брони.
Сценарий «Отмена записи»:
Booking Service меняет статус бронирования и публикует событие BookingCancelled в Брокер сообщений.
Кто слушает (подписчики):
Slot Service освобождает слот, делая его снова доступным для поиска.
Integration Gateway передает команду отмены во внешнюю МИС клиники.
Notification Service отправляет уведомление об отмене пациенту и врачу.

11.

Часть 2. Архитектура
Container diagram
Где хранится состояние
Архитектура четко разделяет stateless (без состояния) и stateful (хранящие состояние)
контейнеры для оптимизации производительности:
Без состояния (Stateless):
• Web / Mobile App (данные хранятся только локально в кэше приложения во время
сессии).
• API Gateway (проверяет JWT на лету, не требует базы данных).
• Integration Gateway (транслирует запросы, не имеет своего постоянного хранилища).
• Notification Service (обрабатывает очередь задач, может использовать оперативный
Redis только для лимитов отправки сообщений).
С хранением состояния (Stateful):
• Catalog Service: использует PostgreSQL. Мастер-данные клиник, врачей, услуг.
• Slot Service: использует связку PostgreSQL + Redis. PostgreSQL – мастер-данные
расписания. Redis – кэш свободных слотов для быстрого поиска
• Booking Service: использует PostgreSQL. ACID-транзакции для исключения двойного
бронирования.
• Message Broker (Kafka / RabbitMQ): персистентное хранение событий до обработки
всеми подписчиками.

12.

Часть 3. REST API
Проектирование REST API
Мы спроектировали три ключевых эндпоинта, которые покрывают весь
жизненный цикл записи:
1. Создание записи
Поле
Endpoint name
HTTP method
URL
Описание сценария
Описание
CreateAppointment
POST
/api/v1/appointments
Создание новой записи
пользователя на медицинскую
услугу в выбранную клинику на
определенный временной слот

13.

Проектирование REST API
2. Получение записи
Поле
Endpoint name
HTTP method
URL
Описание сценария
Описание
GetAppointment
GET
/api/v1/appointments/{
appointment_id}
Получение подробной информации
о конкретной записи по её
идентификатору

14.

Проектирование REST API
3. Отмена записи
Поле
Endpoint name
HTTP method
URL
Описание сценария
Описание
CancelAppointment
DELETE
/api/v1/appointments/{
appointment_id}
Отмена существующей записи на
прием. Выбранный слот
освобождается для других
клиентов.

15.

Часть 4. Kafka события
Так как у нас асинхронная архитектура, мы описали два основных
события, которые проходят через брокер-сообщений.
1. Создание записи
Структура сообщения
Поле
Тип данных
Обязательный
event_id
String (UUID)
Да
event_version
event_time
String
String (ISO 8601)
Да
Да
event_type
String
Да
payload
Object
Да
Описание
Уникальный идентификатор
самого события
Версия схемы события
Дата и время генерации
события
Тип события
(appointment_created)
Данные предметной области

16.

Часть 4. Kafka события
2. Отмена записи
Структура сообщения
Поле
event_id
Тип данных
String (UUID)
Обязательный
Да
event_version
event_time
String
String (ISO 8601)
Да
Да
event_type
String
Да
payload
Object
Да
Описание
Уникальный
идентификатор самого
события
Версия схемы события
Дата и время
генерации события
Тип события
(appointment_cancelled)
Данные предметной
области

17.

Интерпретация данных
Рекомендации для Заказчика и Перспективные направления
для дальнейшей разработки и использования сервиса :
В качестве рекомендаций для развития мы бы предложили следующее:
Внедрение Rate Limiting на уровне API Gateway для защиты от чрезмерных
запросов.
Внедрение распределенного трейсинга (Jaeger/Zipkin) для упрощения
отладки цепочек вызовов
Реализация механизма Circuit Breaker для внешних МИС – при
недоступности клиники не держать пользователя в ожидании, а сразу
возвращать ошибку и откладывать запись в очередь.
Перспективные направления:
Умное бронирование – автоматический подбор ближайших альтернатив.
Мобильное приложение + Push-уведомления.
Интеграция с Госуслугами для верификации личности пациента.

18. Спасибо за внимание!