Упражнение 2: Разбор решения

• Спецификация проекта FoodFleet
• Architectural Requirements Doc
• Статья: Architecturally Significant Requirements — What They Are and Why They Matter

---

Введение

Это разбор решения второго упражнения.
Помни: твой список и мой могут отличаться — и это нормально.

Архитектурно значимые требования зависят от контекста проекта, опыта архитектора и приоритетов команды. Главное — уметь замечать функциональные особенности, которые потенциально влияют на архитектуру.

Мой вариант списка ASR для FoodFleet

1. 👤 Анонимный пользователь и корзина без авторизации

Пользователь может просматривать приложение и добавлять блюда в корзину без входа в систему.

📌 Почему это важно:

• Нужен механизм для отслеживания действий анонимного клиента;
• Возможно, потребуется сущность Visitor (гость);
• При входе — синхронизация корзины между локальным и серверным состоянием.

💡 Вопрос для проработки:

Должны ли мы сохранять корзину гостя при авторизации и как именно происходит синхронизация данных?

2. 🔍 Поиск и автодополнение (Autocomplete)

Пользователь может искать рестораны и блюда по ключевым словам.

📌 Почему это важно:

• Возможна реализация автодополнения — потребует отдельного API-эндпоинта;
• Влияет на структуру поискового сервиса и схему взаимодействия фронтенда с backend;
• Может вызвать вопрос о том, нужно ли создавать общий модуль поиска для разных частей приложения.

💡 Вопрос для проработки:

Используем ли мы централизованный API для автодополнения или отдельные точки для разных сущностей (рестораны, блюда, категории)?

3. ⚡ Реальное время — отслеживание заказов

Пользователь видит статус заказа и карту с перемещением курьера в реальном времени.

📌 Почему это важно:

• Требует реалтайм-инфраструктуры (WebSocket, SSE, Pub/Sub и т.п.);
• Влияет на архитектуру API, нагрузку на сервер, масштабирование;
• Может потребовать централизованный WebSocket-сервер или шлюз событий.

💡 Вопрос для проработки:

Есть ли другие функции, которым тоже нужно real-time взаимодействие (например, обновления заказов у ресторана)?
Если да — стоит ли реализовать общий real-time слой для всех ролей (клиент, ресторан, курьер)?

4. 💬 Отзывы и рейтинги

Пользователь может просматривать рейтинги и отзывы других клиентов.

📌 Почему это важно:

• Подгрузка отзывов не должна блокировать рендеринг страницы ресторана;
• Это влияет на стратегию загрузки данных (lazy loading, suspense, SSR);
• Учитывает требования к производительности (≤5 сек загрузки) из архитектурных атрибутов.

💡 Рекомендация:

Использовать асинхронную загрузку отзывов и кеширование на стороне клиента или CDN.

5. 🚴 Реальное время — интерфейс ресторана и курьера

Владельцы ресторанов и водители видят обновления заказов в реальном времени.

📌 Почему это важно:

• Определяет архитектуру многопользовательского real-time взаимодействия;
• Требует разделения каналов (driver, restaurant, customer) и авторизации событий;
• Влияет на модель сообщений и инфраструктуру брокера событий.

6. 💳 Оплата заказов через внешний сервис

Пользователь оплачивает заказ онлайн через стороннюю систему.

📌 Почему это важно:

• Необходима интеграция с внешним API (например, ЮКасса);
• Требует решения для безопасной обработки токенов и валидации;
• Влияет на модель обмена событиями и обработку ошибок/возвратов.

Выводы

Мой список включает шесть архитектурно значимых функциональных требований:

Итог урока

• Твой список может отличаться — и это прекрасно.
• Главное — начать замечать архитектурные следствия функциональных требований.
• На следующем этапе мы будем превращать эти требования в архитектурные решения.