Обоснование выбора архитектуры и паттерна - shoumq/bybit_scalp GitHub Wiki

Ответственные: Андрей (архитектор), Иван (тимлид), Эльес (тестировщик)

Основные требования к архитектуре:

Быстрая реализация минимального жизнеспособного продукта (MVP) с минимальными DevOps-настройками. Возможность лёгкого добавления новых модулей (новые стратегии, уведомления, аналитика). Минимальные задержки в торговле (особенно для реакции на изменения в стакане). Простота поддержки для небольшой команды из 3 человек. Возможность безопасной обработки реальных торговых операций с контролем ошибок.

  1. Монолитная архитектура

✅ Преимущества:

Быстрый старт:

Один исполняемый файл (Go). Не требует контейнеризации на первом этапе. Быстрая интеграция с Bybit API.

Высокая производительность:

Вызовы между модулями (логика торговли, работа с ордерами, логирование) происходят в памяти — быстрее, чем между сервисами.

Простота тестирования:

Легко покрыть unit- и интеграционными тестами. Проще отлаживать логику и фиксацию ошибок.

Удобство поддержки:

Вся логика и конфигурация в одном месте. Быстрое внесение изменений и отладка.

❌ Недостатки:

Сложность масштабирования: при росте нагрузки усложняется поддержка многопоточности. Ошибки в одном модуле могут затронуть весь бот. Придётся продумывать безопасную работу с потоками (например, при одновременной работе WebSocket и REST).

  1. Микросервисная архитектура

✅ Преимущества:

Изоляция по зонам ответственности (например, один сервис — стратегия, второй — ордера, третий — мониторинг). Возможность масштабировать отдельные модули (например, предсказание цены через ML).

❌ Недостатки:

Требуется DevOps-экспертиза (Docker, message brokers, балансировка). Избыточна для MVP и команды из 3 человек. Возрастает сложность трассировки ошибок и мониторинга.

  1. Clean Architecture

✅ Преимущества:

Разделение бизнес-логики, инфраструктуры и UI. Высокая адаптивность к изменению платформ (например, перенос на другую биржу).

❌ Недостатки:

Сложная организация слоёв, требует высокого уровня подготовки. Затруднён вход для новых участников. Избыточна на начальном этапе.


✅ **Выбор архитектуры — Монолитная архитектура

Монолитная структура обеспечивает баланс между скоростью разработки, производительностью и простотой поддержки. Все модули (сбор данных, прогноз, ордера, логика стратегий, логирование) размещаются в рамках одного бинарного файла на Go.

Выбор паттерна для внутренней организации кода

Требования к паттерну:

Чёткое разделение между бизнес-логикой, взаимодействием с биржей и визуализацией (если есть UI); Возможность подключать новые стратегии и ордер-модули; Высокая тестируемость (особенно логики торговли); Минимальная сложность для команды из 3 человек.

  1. MVC (Model-View-Controller)

✅ Описание:

Model: стратегии, расчёт сигналов, логика выставления ордеров. View: CLI-интерфейс или web-интерфейс, Telegram-бот. Controller: обработка входящих событий (тик с биржи, пользовательская команда, результат ордера), запуск соответствующей логики.

✅ Плюсы:

Простое разделение по зонам ответственности; Быстрое внедрение новых функций (новая стратегия — новый контроллер + модель); Подходит для CLI/web-интерфейса и легко расширяется до API.

❌ Минусы:

При росте проекта потребуется рефакторинг; Возможен конфликт при многопоточности, если не отделить слои безопасно.

  1. MVVM (Model-View-ViewModel)

✅ Преимущества:

Хорошо работает с современными UI (React). Подходит для реализации UI в реальном времени (web-панель бота).

❌ Недостатки:

Неактуален без постоянного UI. Избыточен для CLI/бота.

  1. Layered Architecture (слой бизнес-логики, слой данных, слой API)

✅ Преимущества:

Хорошо масштабируется; Подходит для командной разработки; Можно внедрять поэтапно.

❌ Недостатки:

Требует чёткой дисциплины; Избыточно для CLI или базовой версии.

✅ Выбор паттерна — MVC

MVC подходит для текущих задач:

Контроллеры управляют логикой запуска торгов; Модели — стратегии и торговые сигналы; View — CLI/Telegram/web-интерфейс.

Структура легко расширяется, тестируется, и даёт гибкость при поддержке минимального кода. В будущем можно перейти на Layered Architecture при увеличении команды или добавлении UI/панели мониторинга.