Event Message
Le message-notification — pub/sub temps réel, le pattern du Kafka moderne.
Problème
Comment notifier plusieurs systèmes intéressés d'un changement d'état (ORDERS confirmé, INVOIC payée, conteneur arrivé) sans coupler l'émetteur aux récepteurs ?
Forces
- L'émetteur ne doit pas connaître les destinataires (découplage).
- Les destinataires peuvent traiter à leur rythme (latence variable).
- Les événements doivent être archivables pour replay et debugging.
- Un événement ne se modifie pas — c'est un fait passé.
Solution
Publier l'événement sur un canal Publish-Subscribe. L'émetteur ne sait pas qui écoute. Les abonnés s'enregistrent et réagissent. Convention de nommage : verbe au passé (OrderConfirmed, InvoicePaid, ContainerArrived). Payload immutable, sourcing depuis Event Log pour replay.
Implémentation EDI
En EDI moderne event-driven, les Event Messages représentent les changements d'état des flux : OrderReceived, InvoiceValidated, MdnAcknowledged, EdifactParsed. Architecture : topic Kafka edi.events, chaque service métier (analytics, compliance, dashboard) s'abonne selon son besoin. Event Sourcing complet possible — reconstruire l'état d'un INVOIC depuis ses événements.
Anti-patterns
- Événement nommé au futur ou à l'impératif (CreateOrder) — c'est un Command, pas un Event.
- Émetteur qui attend une réponse — c'est plus du request/reply, pas un Event.
- Événement modifié rétroactivement — un fait passé est immuable.
Patterns liés
- Command Message — pattern complémentaire.
- Document Message — troisième style.
- Publish-Subscribe — canal typique des events.
Sources
- Hohpe G., Woolf B. — EIP, Event Message (p. 151). www.enterpriseintegrationpatterns.com/patterns/messaging/EventMessage.html