Aller au contenu principal

Événements métier

Statut​

Document de cadrage backend — version initiale.

État actuel​

Aucun dossier Events ou Listeners généralisé n'est visible dans api/app/Modules.

Le projet utilise déjà des Jobs et services, mais la stratégie d'événements métier reste une vision cible à formaliser.

Objectif​

Les événements métier servent à signaler qu'un fait important vient de se produire, sans coupler directement tous les traitements.

Exemples possibles :

  • acteur revendiqué ;
  • acteur validé ;
  • publication créée ;
  • publication modérée ;
  • alerte mairie publiée ;
  • boost acheté ;
  • abonnement changé ;
  • invitation AssoSuite envoyée ;
  • device PlayLoop enregistré.

Ces exemples ne signifient pas que ces événements existent déjà.

Quand utiliser un événement​

Utiliser un événement si :

  • plusieurs traitements doivent réagir au même fait ;
  • la réaction peut être asynchrone ;
  • le domaine source ne doit pas connaître tous les consommateurs ;
  • la traçabilité métier est importante.

Éviter un événement si :

  • une méthode directe suffit ;
  • l'ordre d'exécution est critique et immédiat ;
  • l'événement masquerait une dépendance métier forte.

Convention cible​

app/Modules/<Module>/Events/
app/Modules/<Module>/Listeners/

Nommer les événements au passé :

  • PublicationCreated
  • BoostExpired
  • MairieAlertePublished

Relation avec Jobs​

Un événement peut déclencher un listener synchrone ou un job asynchrone.

Pour les traitements lourds :

  • notification ;
  • médias ;
  • statistiques ;
  • IA ;
  • synchronisation ;

le listener doit déléguer à une queue.

Points à clarifier​

  • Choix d'une convention Events/Listeners officielle.
  • Politique d'événements synchrones vs asynchrones.
  • Journalisation des événements métier.
  • Tests des listeners et jobs déclenchés.