Aller au contenu principal

RFC-003 --- Publication & Business Events

Statut​

Draft

Auteur​

Architecture DMV

ADR de référence​

  • ADR-014 --- Bounded Contexts and Modular Monolith

Résumé

Faire de Publication le seul Bounded Context responsable de la diffusion des contenus et standardiser les échanges entre contextes au moyen d'événements métier immuables.

1. Problème

Aujourd'hui, plusieurs modules publient ou déclenchent directement des comportements chez d'autres modules.

Conséquences :

  • dépendances fortes ;
  • écritures croisées ;
  • couplage métier ;
  • difficulté à faire évoluer les fonctionnalités.

2. Contexte

Les autres Bounded Contexts produisent des faits métier.

Publication décide ensuite :

  • si le contenu devient public ;
  • où il est diffusé ;
  • sous quelle forme ;
  • vers quels canaux.

Les événements métier deviennent le contrat standard entre contextes.

3. Objectifs

  • supprimer les appels directs entre contextes ;
  • rendre les échanges explicites ;
  • permettre l'ajout de nouveaux consommateurs sans modifier l'émetteur ;
  • préparer les futures notifications, recherches, IA et analytics.

4. Hors périmètre

  • choix du bus technique ;
  • implémentation Outbox ;
  • notifications utilisateur ;
  • moteur de recherche.

5. Décision

Les Bounded Contexts publient uniquement des Business Events.

Exemples :

MunicipalAlertPublished
AssociationEventCreated
ActorProfileUpdated
PublicationCreated
PublicationArchived

Les événements :

  • sont immuables ;
  • décrivent un fait métier passé ;
  • ne contiennent pas de logique.

Publication devient le propriétaire exclusif de la diffusion publique.

6. Alternatives étudiées

Appels directs entre services​

Rejetée.

Elle crée un couplage fort.

Partage de tables​

Rejetée.

Elle viole les frontières des Bounded Contexts.

7. Impact

Les nouveaux modules (Coach, AssoSuite, MairieSuite...) pourront publier des événements sans connaître les consommateurs.

Les consommateurs pourront évoluer indépendamment.

8. Plan de migration

Étape 1​

Inventorier tous les appels inter-contextes.

Étape 2​

Identifier les Business Events manquants.

Étape 3​

Remplacer progressivement les appels directs par des événements.

Étape 4​

Faire de Publication le point d'entrée unique pour la diffusion publique.

9. Rollback

Chaque remplacement est réalisé indépendamment.

En cas de problème, le producteur peut temporairement revenir à son implémentation précédente.

10. Critères de succès

  • plus aucun appel métier direct entre Bounded Contexts ;
  • Publication est seul responsable de la diffusion ;
  • tous les échanges métier passent par des événements ou des contrats publiés ;
  • les événements sont documentés et versionnés.

11. Risques

  • multiplication d'événements redondants ;
  • événements trop techniques au lieu d'être métier ;
  • consommateurs oubliés lors de la migration.

12. Questions ouvertes

  • convention de nommage des événements ;
  • politique de versionnement ;
  • durée de rétention ;
  • stratégie de rejeu.

Historique

Date Auteur Modification

2026-07 Architecture DMV Création