118 lines
8.0 KiB
Markdown
118 lines
8.0 KiB
Markdown
[Назад](/README.md)
|
||
|
||
# Вопросы по архитектуре TaskManager
|
||
|
||
## 1. Стандартизация сообщений
|
||
- Какие ключевые поля должны быть в стандартизированном сообщении?
|
||
- Например: task_id, source_system, target_system, task_type, priority, description, attachments, due_date
|
||
- Нужна ли поддержка разных типов задач (одноразовые, периодические, срочные)?
|
||
|
||
**Ответ:**
|
||
1. Пока не думал над контрактом, тк это уже детали. Наверно общие поля стоит указать, как минимум для примера. Но контракт точно поменяется, многое будет зависить от выбора решений.
|
||
2. Задачи точно будут одноразовые и периодические
|
||
|
||
|
||
---
|
||
|
||
## 2. Connections-service
|
||
- Связи между системами должны быть двусторонними или направленными?
|
||
- Нужна ли поддержка правил маршрутизации (например, "все задачи типа 'уборка' из System_1 идут в System_2")?
|
||
- Должны ли связи настраиваться динамически через админку без перезапуска сервисов?
|
||
|
||
**Ответ:**
|
||
1. Сложно сказать, наверное правильнее строить односторонние связи. В случае если нам нужна двусторонняя связь, то мы сперва деляем связь от системы 1 к системе 2, а потом отдельную связь от системы 2 к системе 1. Думаю так будет гибче?
|
||
2. Какие то правила наверняка потребуются в будующем, стоит заложится под это, но пока не понятно как это будет
|
||
3. Да связи настраиваются динамически через админку и без перезапуска.
|
||
|
||
|
||
---
|
||
|
||
## 3. Адаптеры
|
||
- Какие типы внешних систем предполагаются для первых адаптеров? (PMS системы, ERP, существующие task-менеджеры?)
|
||
- Адаптеры должны работать по push-модели (отправляют сами) или pull-модели (периодически опрашивают внешние системы)?
|
||
- Нужна ли поддержка WebHooks для интеграций?
|
||
|
||
**Ответ:**
|
||
1. PMS, ERP, управление уборщицами
|
||
2. Суть адаптера в том, что он адаптер. Системы бывают очень разные, гдето есть api, гдето надо будет самому пойти в базу, гдето нужно опрашивать систему, гдето система сама будет отправлять данные. Вообщем каждый адаптер будет уникален, но его задача адаптировать сообщения от\из системы в нашу
|
||
3. Пока сложно сказать, не понятно применение, какие у тебя идеи?
|
||
|
||
|
||
---
|
||
|
||
## 4. Tasks-service
|
||
- Какие основные статусы задачи? (created, assigned, in_progress, completed, cancelled, rejected?)
|
||
- Нужна ли поддержка подзадач и зависимостей между задачами?
|
||
- Нужно ли версионирование задач (история изменений)?
|
||
|
||
**Ответ:**
|
||
1. Пока да, но вероятно пользователь захочет созхдавать "свои" статусы. Поэтому вероятно стоит заложится что в MVP делаем стандартынй набор, а потом чтобы смогли поддержать гибкость
|
||
2. Между задачами точно появятся зависимости. На счет подзадач не уверен, пока откажемся от них
|
||
3. История изменений нужна
|
||
|
||
|
||
---
|
||
|
||
## 5. Безопасность и разграничение доступа
|
||
- Будет ли мультитенантность (несколько отелей в одной инсталляции)?
|
||
- Какие основные роли предполагаются? (admin, manager, department_head, worker?)
|
||
- Нужна ли изоляция данных между отелями?
|
||
|
||
**Ответ:**
|
||
1. Да отелей у компании может быть несколько
|
||
2. админ, техподдержка, и по ролям дальше, все виды сотрудников. скорее всего тоже надо делать настраиваемым, чтобы можно было для отелей настроить свои роли, вдруг там уникальные какието названия
|
||
3. Скорее всего нет, так как тот же маркетинг один на всю сетку отелей. Мы все же говорим что отелей несколько, но владелец один. Тоесть между отелями разных владельцев связей не будет!
|
||
|
||
|
||
---
|
||
|
||
## 6. Масштабирование
|
||
- Сколько отелей планируется поддерживать в одной инсталляции?
|
||
- Какой объем сообщений в день ожидается (примерно)?
|
||
- Kafka будет в одном экземпляре или нужен кластер?
|
||
|
||
**Ответ:**
|
||
1. Может быть разное, от 1 до 50 (а может и больше)
|
||
2. Пока не известно, будем проводить НТ после разработки MVP
|
||
3. Пока предполагаем одну, кажется должно хватить. Разграничивать сообщения топиками.
|
||
|
||
|
||
---
|
||
|
||
## 7. Дополнительные сервисы
|
||
- **File Storage Service** - где хранить фото/файлы? (S3-compatible, локально, CDN?)
|
||
- **Notification Service** - нужны ли уведомления? (email, push, SMS?)
|
||
- **Audit Service** - нужен ли отдельный сервис для аудита действий?
|
||
- **Scheduler Service** - для периодических задач нужен отдельный сервис?
|
||
|
||
**Ответ:**
|
||
1. s3
|
||
2. уведомления нужны: email, push, sms, telegram, max и любые другие месенджеры
|
||
3. да аудит нужен
|
||
4. scheduler тоже нужен
|
||
|
||
|
||
---
|
||
|
||
## 8. Технологический стек
|
||
- Python сервисы - какой фреймворк? (FastAPI, Django, Flask?)
|
||
- Нужна ли REST API Gateway перед всеми сервисами?
|
||
- GraphQL рассматривается или только REST?
|
||
- Контейнеризация (Docker) + оркестрация (Kubernetes, Docker Compose)?
|
||
|
||
**Ответ:**
|
||
1. Пока не понятно. Это уже детали
|
||
2. Rest api нужно для веба. Но еще для веба нужно получать информацию и от сервера. Поэтому вероятно лучше сразу смотреть в grpc + может rest оставить для каких то отдельных запросов
|
||
3. Да, скорее всего кластер кубер. Сервисы по контейнерам с возможностью масштабирования подов
|
||
|
||
|
||
---
|
||
|
||
## 9. Дополнительные вопросы от вас
|
||
Есть ли у вас дополнительные требования или ограничения, которые нужно учесть при проектировании?
|
||
|
||
**Ответ:**
|
||
1. Пока наверно все рассказал
|
||
|
||
|