Workflow Événementiel

⚠️ Cette page peut évoluer à mesure que l'architecture est affinée.

TheoryCraft est construit autour d'une architecture événementielle.
Les données de marché, les mises à jour d'exécution et la logique de stratégie communiquent exclusivement via des événements structurés.

Cette conception assure que la même logique de trading se comporte de manière cohérente en backtesting, paper trading et trading live.

Composants Principaux

Un système TheoryCraft est composé de trois composants conceptuels :

  • MarketSource - produit les événements de données de marché
  • Broker - produit les événements d'exécution et de compte, et reçoit les ordres
  • Engines - consomment les événements et effectuent des tâches spécifiques

Chaque composant opère indépendamment et communique uniquement via des événements.

Flux d'Événements

Deux flux d'événements principaux existent dans le système :

MarketEvents

Les MarketEvents sont émis par le MarketSource lorsque de nouvelles données de marché sont disponibles.

Ils peuvent représenter :

  • Mises à jour de prix (ticks ou bars)
  • Rééchantillonnage de timeframe
  • Indicateurs calculés
  • Métadonnées d'instrument ou de session

Les MarketEvents circulent séquentiellement et représentent le passage du temps de marché.

BrokerEvents

Les BrokerEvents sont émis par le Broker lorsque l'état d'exécution change.

Ils peuvent représenter :

  • Mises à jour du cycle de vie des ordres (soumis, exécuté, annulé)
  • Changements de position
  • Mises à jour du solde du compte

Les BrokerEvents reflètent les conséquences des décisions de trading précédentes.

Les Engines comme Consommateurs d'Événements

Les Engines consomment un ou les deux flux d'événements selon leur responsabilité.

Un Engine :

  • S'abonne aux MarketEvents et/ou BrokerEvents
  • Réagit aux événements selon son rôle
  • Peut émettre de nouveaux artefacts comme des ordres, métriques ou alertes

Les Engines ne communiquent pas directement entre eux. La coordination émerge via les flux d'événements partagés.

Modèle de Diffusion des Événements

MarketSource et le Broker diffusent les événements à tous les Engines.

┌──────────────┐     MarketEvent     ┌──────────┐

│ MarketSource │ ──────────────────► │          │

└──────────────┘                     │  Engine  │

                                     │          │

┌──────────────┐     BrokerEvent     │          │

│    Broker    │ ──────────────────► │          │

└──────────────┘ ◄────────────────── └──────────┘

                   Orders / Queries





MarketSource ──(MarketEvents)──► Engines

Broker ────(BrokerEvents)──────► Engines

Engines ──────(Orders)─────────► Broker

Chaque Engine opère indépendamment et peut être ajouté ou retiré sans affecter le reste du système.

Exécution Causale et Reproductible

Chaque événement représente un point de décision discret.

Les Engines ne réagissent qu'aux informations disponibles au moment de l'événement. Aucune donnée future n'est accessible, éliminant le biais d'anticipation par construction.

Comme les événements sont traités séquentiellement, un replay historique d'événements produit le même comportement qu'une exécution live.

Même Logique, Environnements Différents

Le modèle événementiel permet à la même logique d'Engine de s'exécuter sans modification dans différents environnements :

Backtesting

  • MarketSource rejoue les données historiques
  • Le Broker simule l'exécution
  • Le temps avance aussi vite que les événements sont traités

Paper Trading

  • MarketSource streame les données de marché en temps réel
  • Le Broker simule l'exécution
  • Le temps avance en temps réel

Trading Live

  • MarketSource streame les données de marché en temps réel
  • Le Broker exécute les ordres sur des venues réelles
  • Le temps avance en temps réel

Seules la source de données et la configuration du broker changent. La logique d'Engine reste identique.

Pourquoi l'Événementiel ?

Les systèmes événementiels sont naturellement adaptés au trading :

  • Précision - les événements reflètent la façon dont les marchés évoluent dans le temps
  • Cohérence - logique identique dans tous les environnements
  • Composabilité - les Engines peuvent être combinés de manière flexible
  • Tolérance aux pannes - les composants sont isolés
  • Scalabilité - traitement parallèle des workloads indépendants

Cette architecture favorise la justesse et la reproductibilité plutôt que le débit brut.

Prochaines Étapes

Menu