Architecture pilotée par les événements en Kotlin : des coroutines aux flux réactifs

Architecture pilotée par les événements en Kotlin : pourquoi ce n'est pas qu'une simple tendance

Imaginez que votre application est un mécanisme parfaitement réglé. Chaque rouage sait quand tourner, chaque piston quand se déplacer. Mais que se passe-t-il si un jour vous devez ajouter une nouvelle pièce sans arrêter toute la machine ? Dans une architecture synchrone traditionnelle, cela se transforme souvent en cauchemar : réécriture de modules entiers, test de chaînes d'appels infinies et nuits blanches.

C'est ici qu'intervient l'architecture pilotée par les événements en Kotlin — un paradigme où les composants communiquent via des événements, et non par des appels directs. Kotlin, avec ses coroutines et ses flux réactifs, offre des outils tout simplement idéaux pour cela. Dans cet article, nous ne nous contenterons pas de parler de théorie — nous écrirons du code réel, nous analyserons Kotlin Flow et Channels, et je vous montrerai comment construire un système flexible et évolutif qui ne s'effondrera pas à la première charge.

Qu'est-ce que l'architecture orientée événements en termes simples

Dans l'approche classique (imaginez des microservices qui s'appellent mutuellement via REST), chaque requête est un lien rigide. Le service A appelle le service B, attend une réponse, et si B tombe en panne, tout se casse. Dans l'architecture pilotée par les événements, c'est différent : les composants publient des événements (par exemple, "Commande créée") et s'y abonnent. Personne n'attend personne, personne n'appelle personne directement.

La beauté de Kotlin est qu'il permet d'implémenter ce modèle de manière native, sans avoir recours à des frameworks lourds. Les coroutines fournissent des threads légers, tandis que Channel et Flow sont des bus d'événements prêts à l'emploi.

Regardons un exemple très simple — notre propre EventBus en Kotlin :

import kotlinx.coroutines.*\nimport kotlinx.coroutines.channels.*\n\nclass SimpleEventBus {\n    private val events = Channel<Any>(Channel.UNLIMITED)\n\n    suspend fun publish(event: Any) {\n        events.send(event)\n    }\n\n    suspend fun subscribe(handler: suspend (Any) -> Unit) {\n        for (event in events) {\n            handler(event)\n        }\n    }\n}\n\n// Utilisation\nfun main() = runBlocking {\n    val bus = SimpleEventBus()\n    \n    launch {\n        bus.subscribe { event ->\n            println("Événement reçu : $event")\n        }\n    }\n    \n    delay(100)\n    bus.publish("Bonjour, Event-Driven !")\n    delay(100)\n}

Ce code est la base. Nous créons un canal qui fonctionne comme une file d'attente asynchrone. L'éditeur dépose un événement, l'abonné le récupère. Tout est simple, mais on voit déjà la force de l'architecture pilotée par les événements en Kotlin : l'abonné et l'éditeur ne savent rien l'un de l'autre.

Kotlin Flow : des flux réactifs pour les événements

Channel, c'est bien, mais pour les projets réels, on a souvent besoin de plus : des flux chauds et froids, des transformations, la gestion des erreurs. C'est là qu'intervient Kotlin Flow — une bibliothèque réactive intégrée directement dans le langage.

Flow est parfait pour la programmation asynchrone en Kotlin, lorsque les événements sont générés en continu. Par exemple, les mises à jour des taux de change, les flux d'actualités ou l'état de l'interface utilisateur.

Flux froids vs flux chauds

Il est important de comprendre la différence :

\n
• Flux froid (Cold Stream) — ne commence à fonctionner que lorsqu'un abonné s'y inscrit. Chaque abonné reçoit son propre flux de données.
\n
• Flux chaud (Hot Stream) — fonctionne en permanence, indépendamment des abonnés. Les abonnés tardifs manquent les événements passés.
\n

Pour l'architecture pilotée par les événements, on a généralement besoin de flux chauds. En Kotlin, ils sont implémentés via SharedFlow ou StateFlow.

Exemple — un système de notifications :

import kotlinx.coroutines.*\nimport kotlinx.coroutines.flow.*\n\ndata class Notification(val userId: String, val message: String)\n\nclass NotificationService {\n    private val _notifications = MutableSharedF