Chaque architecture couverte jusqu'à présent - en couches, en oignon, hexagonale, propre - partage un modèle mental synchrone de requête-réponse : un appelant invoque une fonction, attend un résultat et continue. L'architecture événementielle (EDA) est un paradigme fondamentalement différent. Les composants communiquent en produisant et en consommant des événements – des enregistrements de quelque chose qui s'est produit. Le producteur ne sait pas qui consommera l’événement, ni quand. Ce découplage temporel libère une classe de propriétés système (évolutivité, résilience, couplage lâche) que les architectures synchrones ont du mal à atteindre. Cela introduit également une nouvelle classe de problèmes que les architectures synchrones évitent de par leur conception.

Un événement est un enregistrement immuable d'un fait qui s'est déjà produit : 'OrderPlaced', 'PaymentProcessed', 'InventoryReserved'. Les événements sont nommés au passé parce qu’ils décrivent l’histoire et non l’intention. C'est la principale distinction par rapport à une commande (« PlaceOrder »), qui exprime une intention et attend un résultat.
Full content is available with a subscription.
Get full access to all courses on the platform for one year with a single payment.
Unlike other platforms that charge per course, here you get everything for one price, and after one year of use there will be no automatic charge for the following year.