Архитектура QTasks

Этот раздел описывает архитектурные принципы QTasks: как устроен фреймворк на уровне компонентов, потоков выполнения и передачи данных. Здесь не рассматриваются пользовательские возможности, API или примеры использования — фокус сделан исключительно на внутреннем устройстве и инженерных решениях.

QTasks спроектирован как компонентный task‑framework, в котором каждый элемент выполняет строго ограниченную роль и взаимодействует с другими элементами через формализованные контракты данных. Архитектура ориентирована на расширяемость, предсказуемость поведения и возможность замены любого компонента без переписывания системы целиком.

Для кого предназначен этот раздел

Раздел «Архитектура» ориентирован на разработчиков, которые:

• встраивают QTasks в сложные проекты;
• разрабатывают собственные компоненты или плагины;
• анализируют производительность и потоки выполнения;
• принимают архитектурные решения на уровне системы.

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

Базовая философия архитектуры

В основе QTasks лежит принцип минимализма компонентов. Компонент реализует только собственную ответственность и не содержит логики, относящейся к другим уровням системы. За счёт этого достигается:

• слабая связность между частями системы;
• возможность независимой замены брокера, воркера, хранилища и вспомогательных компонентов;
• предсказуемый жизненный цикл задач;
• упрощённое тестирование и отладка.

Архитектура не строится вокруг конкретного транспорта, хранилища или способа выполнения. Эти детали вынесены за пределы ядра и подключаются через реализации абстрактных интерфейсов.

Компонентная модель

QTasks состоит из набора логически независимых компонентов, которые образуют конвейер обработки задач. Компоненты не вызывают друг друга напрямую и не обмениваются бизнес‑объектами. Все взаимодействия происходят через схемы данных и чётко определённые точки входа.

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

Потоки управления и данных

В архитектуре QTasks различаются два типа потоков:

• поток управления — определяет порядок выполнения этапов обработки задачи;
• поток данных — описывает, какие структуры данных передаются между компонентами и в каком виде.

Задача на каждом этапе представлена не функцией и не объектом Python, а схемой данных, пригодной для сериализации, логирования, хранения и передачи между процессами или узлами.

Асинхронность и параллелизм рассматриваются как свойства конкретных компонентов и их окружения, а не как глобальное состояние всей системы.

Границы ответственности

Каждый компонент QTasks имеет чётко очерченную зону ответственности. Компоненты не знают о внутренних деталях реализации друг друга и опираются только на публичные контракты.

Это правило намеренно ограничивает «ум» компонентов, но делает систему устойчивой к росту сложности и появлению новых сценариев использования.

Расширение без изменения контрактов

В QTasks нет «ядра» как отдельного монолита, который нужно расширять. Система состоит из компонентов, связанных контрактами — абстрактными классами и схемами данных.

Расширение достигается двумя базовыми путями:

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

Ключевой принцип здесь — эволюция системы через контракты: пока контракт стабилен, внутренности компонента можно менять свободно, а экосистема вокруг остаётся совместимой.