[JAVA] Architecture d'un bot dirigé par les évènements

Hello,

Actuellement développeur JAVA, je me lance aujourd'hui dans un bot trading.

Je vous présente l'architecture que j'envisage de faire, si ça peut aider certaines personnes et si d'autres peuvent me conseiller ce serait top .

Globalement je souhaiterais découper ce bot en plusieurs micro service et respecter le principe CQRS (séparation de la commande et de la requête) et l'event sourcing (afin de pouvoir retracer chaque action).

Voici la répartition que j'envisage actuellement:

Capture d’écran 2020-12-10 à 20.29.48.png (129.74 Kio) Vu 1366 fois

Pour décrire un peu le cheminement :

• Market API: architecture hexagonal me permettant de changer de broker rapidement, il doit récupérer les informations du broker et sauvegarder en tant qu'évènement dans la base de donnée le prix

• Indicator X: Plusieurs micro service qui se déclenche lorsqu'un évènement de type prix arrive (fait par Market API) et qui calcule l'indicateur (rsi, moyenne mobile...) et qui sauvegarde a leur tour un évènement (exemple: rsi = 72)

• Transform state: Récupère la liste des évènements et fait une projection pour faciliter l'algorithme du bot

• Algo Position: récupère les données de AlgoDB (base nosql) et utilise les différents indicateurs en fonction de l'algorithme

Avec cette architecture, j'envisage par la suite d'ajouter des modules comme "NEWS API" qui récupère l'actualité et détecte si cela peut avoir un impact (exemple stock oil).
Mais également pouvoir générer dynamiquement des algorithmes en se basant sur différent indicateurs, avec des horaires différents jusqu'a trouver un algorithme satisfaisait. (BRUT Force, algo IA...).

Si vous êtes intéressés, je pourrais vous faire des mises à jours régulières.

Salut,

je me forme actuellement à la programmation web, meme si je débute et que je ne comprend pas encore tout les rouages cela m'interesse énormément

Je considèrerais dans l'architecture un algo de money management, en amont de algo position (bien sûr indépendant de Transform state)

@Sims8134 la route et longue mais passionnante, on apprend au quotidien

@Euraed c'est une excellente idée ! Je n'ai pas encore pensé à comment récupérer la valeur de la balance du compte actuellement. Généralement dans les APIs des brokers il ne s'agit pas d'un flux entrant, je devrais faire un batch (exécution toutes les x secondes) pour ensuite envoyer un event qui sera interprété, par l'algo de money management.

Je vais commencer l'implémentation de Market API (qui sera certainement open source) pour l'instant branché à l'api Fix ou Rest de fxcm

Hello, beau projet mais j'ai pas mal de remarques pour t'aiguiller j’espère dans le bon sens , je suis architecte et j'ai eu le malheur de me lancer dans ce chemin long de créer un bot efficace.

1- Le choix du langage me parait mauvais, tu ne trouvera pas d'api pour les brokers et quand tu les trouvera,ce ne sera pas opti car le broker l'aura laissé tomber pour s'orienter vers d'autre langage, les api python sont à jour, car les brokers essayent d'embarquer la communié des data scientist dans le wagon, et les api c seront aussi à jour, car un langage bas niveau et rapide dans l'execution, mais bien évidement rien ne t'emepche de coder ta propre api on se basant sur les routes REST que le broker peut proposer. mais la JVM c'est tjrs pas top (mon avis est subjectif car je déteste java )

2- Pour l'archi, je crois que tu commences gros, et tu te lances dans une usine à gaz, une approche event driven c'est sympa, si t'as envie d'allier ta passion pour le trading et l'informatique pourquoi pas, mais je pense que ce n'est pas adapté, l'event driven et les microservices en informatique posent des problèmes de gestion de transactions (pattern saga) et ton archi va induire des temps de latence, or en trading il faut être dans l'instantané, et si tu rajoutes les latences java, ça va faire beaucoup.

3- le Nosql n'est pas adapté non plus, si tu te concentres sur quelques marchés, et avec quelques mois d'historique, t'aura un tout petit volume, et les données des Marchés sont structurées, c'est l'histoire de quelques colonnes, donc avec du SQL classique c'est mieux, et ça te permettra de déléguer du traitement facilement à ta base ( jointures, agrégation ... ), je ne sais pas ce que tu comptais mettre (Mongo ? Cassandra ? ) mais tu te rajoutes juste une complexité technique.

4- le calcul d'indicateur doit idéalement être fait en temps réel et stocké dans la mémoire du process Bot, c'est souvent léger, car un rsi on va le calculer sur 14 périodes, et on garde pas un grand historique pour déclencher nos conditions, si tu delegues ce calcul à un microservice (encore de la latence), ça veut dire qu'il faudra ajouter une interface de connexion entre ton bot et ton microservice indicateur ? la BDD ? et est ce que t'aura un intérêt de stocker toutes les valeurs de tous les indicateurs ? le seul intérêt est d'améliorer ton robot dans le cadre de service de backtesting.

je pense que ton approche modulaire est bonne, de l'event driven c'est cool aussi, tu peux faire chorégraphier des services autour de l'evenement "Price" avec un broker au milieu (rabbitMq), (voir choregraphy vs orchestration). mais oriente toi plus vers des mi-gros-services que micro-service , faut garder une cohérence dans le bot qui prendra les décisions, et tu pourra coder plus tard un service d'historisation des données à coté dans du NoSql si t'as envie, et un service de backtesting why not.

check aussi sur github y'a pas mal de travaux, je peux te communiquer les repos,
je te souhaite bon courage et bonne chance et mon message a uniquement pour but de te donner un avis externe qui j’espère t'aidera dans ta conception.

Cordialement,
Marouane

Je rejoins Marouane sur le coté usine à gaz.

L'objectif principal doit être de réduire au maximum le temps entre l'arrivée d'un tick et la prise de décision.

Pour cela, il faut consacrer toutes les ressources disponibles à faire tourner l'algo de la stratégie et pas à stocker des informations dans une base de données et a passer en revue une foule d'évènements non pertinents sur le moment.

Tu n'es pas une banque devant gérer des centaines de milliers de clients. Donc tu n'a pas besoin de base de données. Au vu des volumes traités, de simples fichiers à plat sont suffisants et bien plus efficients.

A mon avis, seul le cœur de l'automate doit être géré par des évènements.

Il n'est pas nécessaires non plus de stocker les indicateurs. Sauf exception, Il suffit de les calculer à chaque Bougie.

Pour info, voici l'architecture que j'utilise :

Trading Automatique.png (21.29 Kio) Vu 1307 fois