Domain Events

Décrire les faits passés du domaine

Bootcode IWA-S04 — Semaine 17, Jour 3

Objectifs de la leçon

L'étudiant doit savoir :

1. Créer des événements

Avec les bonnes données readonly

2. Produire des événements

Dans un agrégat

3. Comprendre le découplage

L'agrégat publie, les handlers réagissent

Plan du cours

1

Le concept

Un événement = un fait passé (UserSignedUp, OrderPlaced)

2

La règle de nommage

Toujours au passé, factuel, lié au domaine

3

Commande vs Événement

Intention (futur) vs fait accompli (passé)

4

Pourquoi les événements ?

Historique, audit, découplage

5

Live coding

Un agrégat Article qui produit des événements

Module 1

Qu'est-ce qu'un événement ?

Un fait passé dans le domaine

Un événement = un fait passé

Quelque chose S'EST PASSÉ dans le domaine

Un événement décrit un fait qui a déjà eu lieu — il est immuable

👤

UserSignedUp

Un utilisateur s'est inscrit

📦

OrderPlaced

Une commande a été passée

📝

ArticlePublished

Un article a été publié

💸

PaymentReceived

Un paiement a été reçu

💡 La clé : le passé

On ne dit pas ce qu'on VEUT faire, on dit ce qui S'EST PASSÉ

Analogie : le journal d'un domaine

Un événement = une entrée dans le journal

Le domaine tient un journal de tout ce qui s'y passe

📅 2025-01-15 10:32

UserSignedUp { userId: "u-42", email: "alice@mail.com" }

📅 2025-01-15 10:35

ArticleCreated { articleId: "a-7", title: "Hello DDD" }

📅 2025-01-15 11:00

ArticlePublished { articleId: "a-7", publishedAt: "11:00" }

💡 Chaque entrée est un fait

On ne peut ni modifier ni effacer une entrée — elle est arrivée, point

Module 2

La règle de nommage

Au passé · factuel · lié au domaine

3 règles pour nommer un événement

1️⃣ Toujours au passé

Le verbe est conjugué au passé : Created, SignedUp, Placed

2️⃣ Factuel

On décrit un fait, pas une intention : ArticlePublished ✓ — pas PublishArticle ✗

3️⃣ Lié au domaine (métier)

Le nom parle le langage du métier : UserSignedUp ✓ — pas RowInserted ✗

💡 Le test ultime

Lisez le nom à voix haute : "UserSignedUp" — est-ce que votre métier comprend ?

Nommage : technique vs métier

❌ Nommage technique

RowInserted

RecordSaved

DbUpdated

EmailSentEvent

Le métier ne comprend pas — c'est du jargon de développeur

✅ Nommage métier

UserSignedUp

OrderPlaced

ArticlePublished

WelcomeEmailSent

Le métier comprend — c'est son langage

💡 L'événement parle le langage ubiquitaire

Si votre expert métier ne comprend pas le nom, c'est mauvais signe

Module 3

Commande vs Événement

Intention vs fait accompli

Deux concepts à ne pas confondre

📨 Commande

Une intention — on VEUT faire quelque chose

Tournée vers le futur

CreateArticle

SignUpUser

PlaceOrder

"Je veux créer un article"

📢 Événement

Un fait accompli — ça S'EST PASSÉ

Tourné vers le passé

ArticleCreated

UserSignedUp

OrderPlaced

"Un article a été créé"

💡 La commande précède l'événement

CreateArticle (commande) → ArticleCreated (événement qui en résulte)

CreateArticle vs ArticleCreated

📨 Commande (intention)

class CreateArticle {

constructor(

readonly title: string,

readonly content: string,

readonly authorId: string,

) {}

}

"Je veux créer cet article" — peut échouer

📢 Événement (fait)

class ArticleCreated {

constructor(

readonly articleId: string,

readonly title: string,

readonly occurredAt: Date,

) {}

}

"L'article a été créé" — c'est fait, immuable

💡 La différence visible

La commande contient ce qu'on VEUT faire — l'événement contient ce qui S'EST PASSÉ + un horodatage

Module 4

Pourquoi les événements ?

Historique · Audit · Découplage

Historique & audit

Tout est tracé

Chaque événement est une trace immuable de ce qui s'est passé

📜

Historique complet

On peut rejouer l'historique pour reconstruire l'état actuel

🔍

Audit

"Qui a fait quoi et quand ?" — la réponse est dans les événements

// L'historique d'un article

ArticleCreated { articleId: "a-7", title: "Hello" }

ArticleEdited { articleId: "a-7", newTitle: "Hello DDD" }

ArticlePublished { articleId: "a-7", at: "11:00" }

💡 C'est la base de l'event sourcing (S18)

On reconstruit l'état en rejouant les événements — comme un Git log

Le découplage : l'avantage majeur

L'émetteur ne connaît pas les récepteurs

L'agrégat publie un événement — il ne sait PAS qui va réagir

🧠 Agrégat Article

Produit ArticlePublished

↓ publie l'événement ↓

ArticlePublished { articleId, title, at }

↓ des handlers y réagissent, indépendamment ↓

📧 EmailHandler

Notifie les abonnés

📊 StatsHandler

Met à jour les stats

🔍 IndexHandler

Indexe pour la recherche

💡 L'agrégat ne sait pas qu'ils existent

On peut ajouter/supprimer des handlers sans toucher à l'agrégat

Module 5

Live coding

Un agrégat Article qui produit des événements

1️⃣ La classe d'événement

Une classe simple avec des données readonly — aucune logique

// domain/events/ArticleCreated.ts

export class ArticleCreated {

constructor(

readonly articleId: string,

readonly title: string,

readonly authorId: string,

readonly occurredAt: Date = new Date(),

) {}

}

💡 3 choses à remarquer

1️⃣ Tout est readonly — immuable · 2️⃣ Aucune méthode, juste des données · 3️⃣ Un horodatage par défaut

2️⃣ L'agrégat produit des événements

L'agrégat collecte les événements qu'il déclenche

// domain/aggregates/Article.ts

export class Article {

private events: object[] = [];

constructor(

readonly id: string,

readonly title: string,

readonly authorId: string,

) {

// L'agrégat publie un événement

this.events.push(new ArticleCreated(

id, title, authorId

));

}

pullEvents(): object[] {

const copy = [...this.events];

this.events = [];

return copy;

}

💡 L'agrégat ne sait pas qui réagit

Il se contente de collecter les événements — on les récupère avec pullEvents()

3️⃣ Le handler réagit à l'événement

Un handler est totalement indépendant de l'agrégat

// infra/handlers/NotifySubscribersOnArticleCreated.ts

export class NotifySubscribersOnArticleCreated {

constructor(private mailer: Mailer) {}

async handle(event: ArticleCreated): Promise<void> {

// Réagit au fait : un article a été créé

const subscribers = await this.getSubscribers();

for (const sub of subscribers) {

await this.mailer.send(sub.email, {

subject: "Nouvel article : " + event.title,

});

}

💡 Le handler ne connaît que l'événement

Il ne sait pas que l'événement vient d'un Article — découplage total

Le flux complet

Agrégat → Événement → Handler

1️⃣ L'agrégat agit

Un Article est créé — l'agrégat publie ArticleCreated

↓

2️⃣ L'événement est collecté

article.pullEvents() retourne les événements accumulés

↓

3️⃣ Les handlers réagissent

Chaque handler reçoit l'événement et fait son travail, indépendamment

const article = new Article(id, title, authorId);

const events = article.pullEvents();

// → dispatcher.dispatch(events) → handlers

Pièges courants à éviter

❌ Confondre commande et événement

✅ Insister sur passé vs futur : CreateArticle (commande) ≠ ArticleCreated (événement)

❌ Nommer les événements de façon technique

✅ Utiliser le langage métier : RowInserted ✗ → UserSignedUp ✓

❌ Vouloir modifier ou supprimer un événement

✅ Un événement est un fait — il est immuable. On ne le change pas, on en produit un nouveau

Lien avec la Semaine 18

Les événements sont la base de l'event sourcing

La semaine prochaine, on pousse le concept plus loin

📦

Aujourd'hui (S17)

L'agrégat produit des événements en plus de changer d'état

🔮

Semaine 18 (Event Sourcing)

L'état EST reconstruit en rejouant les événements — comme un Git log

💡 Ce que vous apprenez aujourd'hui prépare S18

Maîtriser les événements maintenant = event sourcing plus facile ensuite

À retenir !

⏪

Événement = passé

ArticleCreated, pas CreateArticle

🔌

Découplage total

L'émetteur ne connaît pas les récepteurs

📦

Classe simple, données readonly

Aucune logique — juste des faits

🔒

Immuable

Un événement est un fait — on ne le modifie pas

Questions ?

Créez un agrégat qui produit un événement dans votre projet

Demain : Bounded Contexts — délimiter son domaine