vault backup: 2025-08-13 17:37:19
This commit is contained in:
Andrey Epifancev
@@ -1,38 +1,470 @@
|
|||||||
## 📝 Задача: Система управления событиями
|
### 📝 10 прикладных задач для Middle Java-разработчика
|
||||||
|
|
||||||
|
## 🎯 Задача 1: Система управления складскими операциями
|
||||||
|
|
||||||
### **Условие:**
|
### **Условие:**
|
||||||
|
|
||||||
Вы разрабатываете систему для управления событиями (конференции, вебинары, встречи). Нужно реализовать сервис регистрации участников с учетом следующих требований:
|
Вы разрабатываете модуль WMS для управления операциями приемки товаров на склад. Система должна обрабатывать поступление товаров от поставщиков.
|
||||||
|
|
||||||
1. **Событие** имеет:
|
1. **Поставка** имеет:
|
||||||
|
|
||||||
- ID, название, описание
|
- ID, номер поставки, поставщик
|
||||||
- Дату начала и окончания
|
- Плановую и фактическую дату прибытия
|
||||||
- Максимальное количество участников
|
- Статус (PLANNED, ARRIVED, IN_PROGRESS, COMPLETED, CANCELLED)
|
||||||
- Статус (DRAFT, PUBLISHED, CANCELLED)
|
2. **Товарная позиция** содержит:
|
||||||
2. **Участник** имеет:
|
|
||||||
|
|
||||||
- ID, имя, email
|
- SKU товара, плановое количество
|
||||||
- Дату регистрации
|
- Фактически принятое количество
|
||||||
|
- Статус приемки (PENDING, ACCEPTED, REJECTED, PARTIAL)
|
||||||
3. **Бизнес-правила:**
|
3. **Бизнес-правила:**
|
||||||
|
|
||||||
- Регистрация возможна только на опубликованные события
|
- Приемка возможна только для прибывших поставок
|
||||||
- Нельзя зарегистрироваться на событие, которое уже началось
|
- Нельзя принять больше товара, чем заявлено в поставке
|
||||||
- Нельзя превысить лимит участников
|
- При расхождениях создается акт о расхождениях
|
||||||
- Один участник может зарегистрироваться на событие только один раз
|
- После завершения приемки обновляется остаток на складе
|
||||||
- При отмене события нужно уведомить всех участников
|
- При отмене поставки нужно освободить зарезервированные ячейки
|
||||||
|
|
||||||
### **Техническое задание:**
|
### **Техническое задание:**
|
||||||
|
|
||||||
**Опишите подход к решению задачи:**
|
Опишите подход к решению:
|
||||||
|
|
||||||
1. **Архитектуру приложения** - какие слои нужны
|
1. **Архитектуру приложения** - слои и компоненты
|
||||||
2. **Entity классы** - основные поля и связи
|
2. **Entity классы** - модель данных
|
||||||
3. **Ключевые методы EventRegistrationService**
|
3. **Ключевые методы ReceivingService**
|
||||||
4. **Обработку бизнес-правил** - где и как валидировать
|
4. **Валидацию бизнес-правил**
|
||||||
5. **REST API endpoints** - какие нужны
|
5. **REST API endpoints**
|
||||||
6. **Обработку ошибок** - типы исключений
|
6. **Обработку исключений**
|
||||||
7. **Транзакции** - где нужны и почему
|
7. **Управление транзакциями**
|
||||||
8. **Тестирование** - что важно покрыть тестами
|
8. **Стратегию тестирования**
|
||||||
|
|
||||||
**Время на выполнение:** 25 минут
|
**Время:** 25 минут
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🎯 Задача 2: Система уведомлений с приоритизацией
|
||||||
|
|
||||||
|
### **Условие:**
|
||||||
|
|
||||||
|
Разрабатывается сервис уведомлений для корпоративного приложения. Система должна отправлять уведомления различными каналами с учетом приоритетов.
|
||||||
|
|
||||||
|
1. **Уведомление** содержит:
|
||||||
|
|
||||||
|
- ID, получатель, тема, содержание
|
||||||
|
- Приоритет (LOW, NORMAL, HIGH, CRITICAL)
|
||||||
|
- Каналы доставки (EMAIL, SMS, PUSH)
|
||||||
|
- Статус (PENDING, SENT, FAILED, DELIVERED)
|
||||||
|
2. **Шаблон уведомления** имеет:
|
||||||
|
|
||||||
|
- Тип события, шаблон сообщения
|
||||||
|
- Настройки каналов по умолчанию
|
||||||
|
- Параметры для подстановки
|
||||||
|
3. **Бизнес-правила:**
|
||||||
|
|
||||||
|
- CRITICAL уведомления отправляются немедленно всеми каналами
|
||||||
|
- HIGH - в течение 5 минут, предпочтительные каналы
|
||||||
|
- NORMAL - батчами каждые 15 минут
|
||||||
|
- LOW - раз в час группами
|
||||||
|
- При неудаче повторная отправка через экспоненциальный backoff
|
||||||
|
- Дедупликация одинаковых уведомлений
|
||||||
|
|
||||||
|
### **Техническое задание:**
|
||||||
|
|
||||||
|
Опишите:
|
||||||
|
|
||||||
|
1. **Архитектуру решения** - асинхронная обработка
|
||||||
|
2. **Модель данных** - entities и relationships
|
||||||
|
3. **NotificationService методы**
|
||||||
|
4. **Стратегию приоритизации**
|
||||||
|
5. **API для создания уведомлений**
|
||||||
|
6. **Error handling и retry логику**
|
||||||
|
7. **Использование очередей**
|
||||||
|
8. **Тестирование асинхронных процессов**
|
||||||
|
|
||||||
|
**Время:** 25 минут
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🎯 Задача 3: Система управления задачами роботов
|
||||||
|
|
||||||
|
### **Условие:**
|
||||||
|
|
||||||
|
Создается система для управления автоматизированными роботами на складе. Роботы выполняют задачи перемещения товаров между локациями.
|
||||||
|
|
||||||
|
1. **Робот** имеет:
|
||||||
|
|
||||||
|
- ID, тип, текущая локация
|
||||||
|
- Статус (IDLE, BUSY, MAINTENANCE, ERROR)
|
||||||
|
- Грузоподъемность, заряд батареи
|
||||||
|
- Текущая задача
|
||||||
|
2. **Задача** содержит:
|
||||||
|
|
||||||
|
- ID, тип операции (MOVE, PICK, PLACE)
|
||||||
|
- Локация источник и назначение
|
||||||
|
- Приоритет, крайний срок выполнения
|
||||||
|
- Статус (QUEUED, ASSIGNED, IN_PROGRESS, COMPLETED, FAILED)
|
||||||
|
3. **Бизнес-правила:**
|
||||||
|
|
||||||
|
- Задачи назначаются ближайшему свободному роботу
|
||||||
|
- Учитывается грузоподъемность и тип робота
|
||||||
|
- При низком заряде робот отправляется на зарядку
|
||||||
|
- Высокоприоритетные задачи могут прерывать обычные
|
||||||
|
- При сбое задача переназначается другому роботу
|
||||||
|
|
||||||
|
### **Техническое задание:**
|
||||||
|
|
||||||
|
Опишите:
|
||||||
|
|
||||||
|
1. **Системную архитектуру**
|
||||||
|
2. **Доменную модель**
|
||||||
|
3. **RobotTaskService логику**
|
||||||
|
4. **Алгоритм назначения задач**
|
||||||
|
5. **API для управления роботами**
|
||||||
|
6. **Обработку сбоев**
|
||||||
|
7. **Coordination между роботами**
|
||||||
|
8. **Тестирование concurrent операций**
|
||||||
|
|
||||||
|
**Время:** 25 минут
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🎯 Задача 4: Система управления скидками и промокодами
|
||||||
|
|
||||||
|
### **Условие:**
|
||||||
|
|
||||||
|
Разрабатывается модуль для e-commerce платформы, управляющий скидками и промокодами с различными условиями применения.
|
||||||
|
|
||||||
|
1. **Скидка** имеет:
|
||||||
|
|
||||||
|
- ID, название, описание
|
||||||
|
- Тип (PERCENTAGE, FIXED_AMOUNT, FREE_SHIPPING)
|
||||||
|
- Значение скидки
|
||||||
|
- Период действия, лимит использований
|
||||||
|
2. **Промокод** содержит:
|
||||||
|
|
||||||
|
- Код, связанная скидка
|
||||||
|
- Условия применения (минимальная сумма, категории товаров)
|
||||||
|
- Количество использований на пользователя
|
||||||
|
- Статус (ACTIVE, EXPIRED, EXHAUSTED)
|
||||||
|
3. **Бизнес-правила:**
|
||||||
|
|
||||||
|
- Промокод можно применить только к подходящим товарам
|
||||||
|
- Один заказ может содержать несколько скидок
|
||||||
|
- Скидки применяются в порядке приоритета
|
||||||
|
- Нельзя превысить максимальный процент скидки (например, 80%)
|
||||||
|
- Скидки на доставку несовместимы друг с другом
|
||||||
|
|
||||||
|
### **Техническое задание:**
|
||||||
|
|
||||||
|
Опишите:
|
||||||
|
|
||||||
|
1. **Архитектуру модуля**
|
||||||
|
2. **Entity модель**
|
||||||
|
3. **DiscountService функциональность**
|
||||||
|
4. **Логику валидации и применения**
|
||||||
|
5. **REST endpoints**
|
||||||
|
6. **Обработку конфликтов скидок**
|
||||||
|
7. **Транзакционность операций**
|
||||||
|
8. **Unit и integration тесты**
|
||||||
|
|
||||||
|
**Время:** 25 минут
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🎯 Задача 5: Система резервирования ресурсов
|
||||||
|
|
||||||
|
### **Условие:**
|
||||||
|
|
||||||
|
Создается система для резервирования переговорных комнат, оборудования и других ресурсов в офисе компании.
|
||||||
|
|
||||||
|
1. **Ресурс** имеет:
|
||||||
|
|
||||||
|
- ID, название, тип (ROOM, EQUIPMENT, VEHICLE)
|
||||||
|
- Вместимость, локация
|
||||||
|
- Доступное время работы
|
||||||
|
- Статус (AVAILABLE, OCCUPIED, MAINTENANCE)
|
||||||
|
2. **Резервирование** содержит:
|
||||||
|
|
||||||
|
- ID, пользователь, ресурс
|
||||||
|
- Время начала и окончания
|
||||||
|
- Цель использования
|
||||||
|
- Статус (PENDING, CONFIRMED, CANCELLED, COMPLETED)
|
||||||
|
3. **Бизнес-правила:**
|
||||||
|
|
||||||
|
- Нельзя забронировать занятый ресурс
|
||||||
|
- Резервирование возможно только на будущее время
|
||||||
|
- Автоматическая отмена неподтвержденных бронирований через 15 минут
|
||||||
|
- Recurring резервирования (еженедельные встречи)
|
||||||
|
- Приоритет для VIP пользователей
|
||||||
|
|
||||||
|
### **Техническое задание:**
|
||||||
|
|
||||||
|
Опишите:
|
||||||
|
|
||||||
|
1. **Системную архитектуру**
|
||||||
|
2. **Модель данных**
|
||||||
|
3. **ReservationService методы**
|
||||||
|
4. **Conflict resolution логику**
|
||||||
|
5. **API endpoints**
|
||||||
|
6. **Exception handling**
|
||||||
|
7. **Scheduled tasks для cleanup**
|
||||||
|
8. **Тестирование concurrent бронирований**
|
||||||
|
|
||||||
|
**Время:** 25 минут
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🎯 Задача 6: Система мониторинга производительности API
|
||||||
|
|
||||||
|
### **Условие:**
|
||||||
|
|
||||||
|
Разрабатывается система для мониторинга производительности и доступности API endpoints различных микросервисов.
|
||||||
|
|
||||||
|
1. **API Endpoint** имеет:
|
||||||
|
|
||||||
|
- URL, HTTP метод, сервис
|
||||||
|
- SLA параметры (latency, availability)
|
||||||
|
- Частота проверок
|
||||||
|
- Критичность (LOW, MEDIUM, HIGH, CRITICAL)
|
||||||
|
2. **Метрика** содержит:
|
||||||
|
|
||||||
|
- Timestamp, endpoint, response time
|
||||||
|
- HTTP статус код, размер ответа
|
||||||
|
- Статус проверки (SUCCESS, TIMEOUT, ERROR)
|
||||||
|
3. **Бизнес-правила:**
|
||||||
|
|
||||||
|
- Критичные endpoints проверяются каждые 30 секунд
|
||||||
|
- Обычные - каждые 5 минут
|
||||||
|
- При превышении SLA генерируется alert
|
||||||
|
- Escalation при множественных сбоях
|
||||||
|
- Автоматическое отключение проблемных endpoints из балансировщика
|
||||||
|
|
||||||
|
### **Техническое задание:**
|
||||||
|
|
||||||
|
Опишите:
|
||||||
|
|
||||||
|
1. **Архитектуру monitoring системы**
|
||||||
|
2. **Data model**
|
||||||
|
3. **MonitoringService функции**
|
||||||
|
4. **Alerting механизм**
|
||||||
|
5. **Reporting API**
|
||||||
|
6. **Circuit breaker интеграцию**
|
||||||
|
7. **Async обработку проверок**
|
||||||
|
8. **Performance тестирование**
|
||||||
|
|
||||||
|
**Время:** 25 минут
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🎯 Задача 7: Система управления документооборотом
|
||||||
|
|
||||||
|
### **Условие:**
|
||||||
|
|
||||||
|
Создается система для управления корпоративными документами с workflow для согласования и утверждения.
|
||||||
|
|
||||||
|
1. **Документ** имеет:
|
||||||
|
|
||||||
|
- ID, название, тип, версия
|
||||||
|
- Автор, дата создания
|
||||||
|
- Содержимое, вложения
|
||||||
|
- Статус (DRAFT, REVIEW, APPROVED, REJECTED, ARCHIVED)
|
||||||
|
2. **Workflow** содержит:
|
||||||
|
|
||||||
|
- Этапы согласования
|
||||||
|
- Участники (роли или конкретные пользователи)
|
||||||
|
- Условия перехода между этапами
|
||||||
|
- Временные ограничения
|
||||||
|
3. **Бизнес-правила:**
|
||||||
|
|
||||||
|
- Документ проходит все этапы workflow по порядку
|
||||||
|
- На каждом этапе могут быть множественные approvers
|
||||||
|
- При отклонении документ возвращается автору
|
||||||
|
- Возможны параллельные и условные этапы
|
||||||
|
- Автоматическая эскалация при превышении сроков
|
||||||
|
|
||||||
|
### **Техническое задание:**
|
||||||
|
|
||||||
|
Опишите:
|
||||||
|
|
||||||
|
1. **Архитектурный подход**
|
||||||
|
2. **Domain model**
|
||||||
|
3. **WorkflowService логику**
|
||||||
|
4. **State management**
|
||||||
|
5. **Document API**
|
||||||
|
6. **Notification интеграцию**
|
||||||
|
7. **Versioning стратегию**
|
||||||
|
8. **Тестирование workflow сценариев**
|
||||||
|
|
||||||
|
**Время:** 25 минут
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🎯 Задача 8: Система управления инвентаризацией
|
||||||
|
|
||||||
|
### **Условие:**
|
||||||
|
|
||||||
|
Разрабатывается модуль для проведения инвентаризации товаров на складе с поддержкой различных методов подсчета.
|
||||||
|
|
||||||
|
1. **Инвентаризация** имеет:
|
||||||
|
|
||||||
|
- ID, дата проведения, ответственный
|
||||||
|
- Тип (FULL, PARTIAL, CYCLE_COUNT)
|
||||||
|
- Зоны склада для проверки
|
||||||
|
- Статус (PLANNED, IN_PROGRESS, COMPLETED, CANCELLED)
|
||||||
|
2. **Позиция инвентаризации** содержит:
|
||||||
|
|
||||||
|
- SKU товара, локация
|
||||||
|
- Ожидаемое количество (по системе)
|
||||||
|
- Фактическое количество (по подсчету)
|
||||||
|
- Расхождение, причина расхождения
|
||||||
|
3. **Бизнес-правила:**
|
||||||
|
|
||||||
|
- Во время инвентаризации блокируются операции в проверяемых зонах
|
||||||
|
- Расхождения свыше порога требуют пересчета
|
||||||
|
- Автоматическая корректировка остатков после утверждения
|
||||||
|
- Генерация отчетов о расхождениях
|
||||||
|
- Cycle counting по ABC анализу
|
||||||
|
|
||||||
|
### **Техническое задание:**
|
||||||
|
|
||||||
|
Опишите:
|
||||||
|
|
||||||
|
1. **Системную архитектуру**
|
||||||
|
2. **Модель данных**
|
||||||
|
3. **InventoryService методы**
|
||||||
|
4. **Locking механизм**
|
||||||
|
5. **API для mobile приложений**
|
||||||
|
6. **Exception scenarios**
|
||||||
|
7. **Concurrency control**
|
||||||
|
8. **Accuracy testing**
|
||||||
|
|
||||||
|
**Время:** 25 минут
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🎯 Задача 9: Система управления конфигурациями
|
||||||
|
|
||||||
|
### **Условие:**
|
||||||
|
|
||||||
|
Создается централизованная система управления конфигурациями для множества микросервисов с поддержкой версионирования и hot reload.
|
||||||
|
|
||||||
|
1. **Конфигурация** имеет:
|
||||||
|
|
||||||
|
- Ключ, значение, тип данных
|
||||||
|
- Сервис, окружение (dev/test/prod)
|
||||||
|
- Версия, дата изменения
|
||||||
|
- Статус (DRAFT, ACTIVE, DEPRECATED)
|
||||||
|
2. **Изменение конфигурации** содержит:
|
||||||
|
|
||||||
|
- Старое и новое значение
|
||||||
|
- Автор изменения, комментарий
|
||||||
|
- Время применения
|
||||||
|
- Статус применения
|
||||||
|
3. **Бизнес-правила:**
|
||||||
|
|
||||||
|
- Изменения в prod требуют дополнительного утверждения
|
||||||
|
- Возможность отката к предыдущей версии
|
||||||
|
- Валидация значений по схеме
|
||||||
|
- Encrypted значения для sensitive данных
|
||||||
|
- Audit trail всех изменений
|
||||||
|
|
||||||
|
### **Техническое задание:**
|
||||||
|
|
||||||
|
Опишите:
|
||||||
|
|
||||||
|
1. **Architecture design**
|
||||||
|
2. **Data model**
|
||||||
|
3. **ConfigurationService API**
|
||||||
|
4. **Validation framework**
|
||||||
|
5. **REST API design**
|
||||||
|
6. **Security considerations**
|
||||||
|
7. **Version control strategy**
|
||||||
|
8. **Integration testing approach**
|
||||||
|
|
||||||
|
**Время:** 25 минут
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🎯 Задача 10: Система аналитики пользовательского поведения
|
||||||
|
|
||||||
|
### **Условие:**
|
||||||
|
|
||||||
|
Разрабатывается система для сбора и анализа событий пользовательского поведения в веб-приложении с real-time обработкой.
|
||||||
|
|
||||||
|
1. **Событие** имеет:
|
||||||
|
|
||||||
|
- ID, тип события, пользователь
|
||||||
|
- Timestamp, session ID
|
||||||
|
- Метаданные (страница, действие, параметры)
|
||||||
|
- Источник (web, mobile, api)
|
||||||
|
2. **Сессия** содержит:
|
||||||
|
|
||||||
|
- ID сессии, пользователь
|
||||||
|
- Время начала и окончания
|
||||||
|
- Количество событий, страниц
|
||||||
|
- Conversion events
|
||||||
|
3. **Бизнес-правила:**
|
||||||
|
|
||||||
|
- События обрабатываются в real-time
|
||||||
|
- Агрегация метрик по различным измерениям
|
||||||
|
- Обнаружение аномалий в поведении
|
||||||
|
- GDPR compliance - возможность удаления данных пользователя
|
||||||
|
- Retention анализ и funnel metrics
|
||||||
|
|
||||||
|
### **Техническое задание:**
|
||||||
|
|
||||||
|
Опишите:
|
||||||
|
|
||||||
|
1. **Event-driven архитектуру**
|
||||||
|
2. **Data schema design**
|
||||||
|
3. **AnalyticsService компоненты**
|
||||||
|
4. **Real-time processing pipeline**
|
||||||
|
5. **Query API для дашбордов**
|
||||||
|
6. **Privacy compliance**
|
||||||
|
7. **Stream processing с Kafka**
|
||||||
|
8. **Load testing стратегию**
|
||||||
|
|
||||||
|
**Время:** 25 минут
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 📋 Рекомендации по оценке решений
|
||||||
|
|
||||||
|
### **Критерии оценки (для каждой задачи):**
|
||||||
|
|
||||||
|
**Архитектура (25%):**
|
||||||
|
|
||||||
|
- Правильное разделение на слои
|
||||||
|
- Понимание принципов SOLID
|
||||||
|
- Separation of concerns
|
||||||
|
|
||||||
|
**Модель данных (20%):**
|
||||||
|
|
||||||
|
- Корректное проектирование entities
|
||||||
|
- Понимание relationships
|
||||||
|
- Учет performance implications
|
||||||
|
|
||||||
|
**Бизнес-логика (25%):**
|
||||||
|
|
||||||
|
- Правильная обработка бизнес-правил
|
||||||
|
- Валидация и error handling
|
||||||
|
- Edge cases consideration
|
||||||
|
|
||||||
|
**API Design (15%):**
|
||||||
|
|
||||||
|
- RESTful principles
|
||||||
|
- Proper HTTP methods и status codes
|
||||||
|
- Request/Response design
|
||||||
|
|
||||||
|
**Качество кода (15%):**
|
||||||
|
|
||||||
|
- Тестирование стратегия
|
||||||
|
- Transaction management
|
||||||
|
- Exception handling
|
||||||
|
|
||||||
|
### **Уровни оценки:**
|
||||||
|
|
||||||
|
- **Senior level:** Полное решение со всеми деталями, best practices, edge cases
|
||||||
|
- **Middle level:** Основные компоненты покрыты, базовая архитектура правильная
|
||||||
|
- **Junior level:** Базовое понимание задачи, простое решение
|
||||||
|
|
||||||
|
Каждая задача покрывает ключевые навыки Middle разработчика и может быть адаптирована под специфику вашей складской логистики добавлением warehouse-specific деталей.
|
||||||
Reference in New Issue
Block a user