Implementation core/

Agrégats event-sourcés, value objects, erreurs métier et interfaces de repositories

Bootcode IWA-S04 — Semaine 21, Jour 2

Objectifs du jour

1. Implémenter au moins 2 agrégats event-sourcés fonctionnels

Avec pattern init/restore et méthodes métier

2. Créer au moins 1 value object avec validation

Immutable, validé à la construction, private constructor

3. Définir les erreurs métier

DomainError pour chaque règle violée

4. Écrire au moins 4 use cases avec Usecase<I, O>

Chaque use case orchestre un agrégat et un repository

Plan du cours

1

Rappel : la structure core/

agrégats, value objects, repositories, usecases, errors

2

Tips : l'ordre d'implémentation

Événements → agrégat → value objects → use cases

3

Circuler et débloquer

Questions d'architecture, dépendances, invariants

4

Point collectif à mi-journée

Questions communes, retours d'expérience

La structure core/

Le domaine pur — zéro dépendance externe

# src/core/

domain/

Book.ts # agrégat

Loan.ts # agrégat

BookId.ts, ISBN.ts # value objects

events/

BookAdded.ts, BookBorrowed.ts

errors/

BookAlreadyBorrowedError.ts

repositories/

BookRepository.ts # interface abstraite

usecases/

BorrowBook.ts, ReturnBook.ts

💡 Aucun import de typeorm, inversify, express dans core/. C'est la règle absolue.

L'ordre d'implémentation

Suivez cet ordre — chaque étape débloque la suivante

1️⃣

Les événements

Ce qui se passe : BookAdded, BookBorrowed, BookReturned

2️⃣

L'agrégat

init/restore + méthodes métier qui produisent les événements

3️⃣

Les value objects

BookId, ISBN — avec validation

4️⃣

Les erreurs métier

Une DomainError par règle violée

5️⃣

Les use cases

Orchestrent agrégat + repository

Définir un événement

Au passé, immutable, contient les données de la transition

import { BookId } from '../domain/BookId';

import { MemberId } from '../domain/MemberId';

export class BookBorrowed {

constructor(

public readonly bookId: BookId,

public readonly memberId: MemberId,

public readonly borrowedAt: Date

) {}

}

💡 L'événement capture l'état après la transition. Pas besoin de stocker l'état avant — on rejoue depuis le début.

Le pattern init/restore

Deux factory methods : une pour créer, une pour reconstruire depuis l'historique

export class Book extends AggregateRoot<BookEvent> {

private id: BookId;

private isBorrowed = false;

// 1️⃣ Création — produit l'événement initial

static init(id: BookId, isbn: ISBN): Book {

const book = new Book();

book.recordEvent(new BookAdded(id, isbn));

return book;

}

// 2️⃣ Rebuild — rejoue l'historique

static restore(events: BookEvent[]): Book {

const book = new Book();

events.forEach(e => book.apply(e));

return book;

}

apply() — muter l'état depuis un événement

La méthode apply est privée — seul restore() l'appelle

private apply(event: BookEvent): void {

if (event instanceof BookAdded) {

this.id = event.bookId;

this.isbn = event.isbn;

this.isBorrowed = false;

} else if (event instanceof BookBorrowed) {

this.isBorrowed = true;

} else if (event instanceof BookReturned) {

this.isBorrowed = false;

}

💡 apply() ne fait que muter l'état. Elle ne valide rien, ne lance pas d'erreur — l'événement est un fait acquis.

La méthode métier borrow()

Valide l'invariant, puis produit l'événement

borrow(memberId: MemberId): void {

// 1. Valider l'invariant

if (this.isBorrowed) {

throw new BookAlreadyBorrowedError(this.id);

}

// 2. Produire l'événement

this.recordEvent(

new BookBorrowed(this.id, memberId, new Date())

);

// 3. Appliquer immédiatement

this.isBorrowed = true;

}

⚠️ L'ordre compte : valider AVANT de produire l'événement. Sinon on crée un événement pour une transition illégale.

Value Object avec validation

Private constructor + factory statique qui valide

export class ISBN {

private constructor(public readonly value: string) {}

static create(raw: string): ISBN {

const cleaned = raw.replace(/-/g, '');

if (!isValidIsbn13(cleaned)) {

throw new InvalidISBNError(raw);

}

return new ISBN(cleaned);

}

✅ ISBN.create("978-3-16-148410-0") → instance valide

❌ ISBN.create("abc") → InvalidISBNError

Les erreurs métier (DomainError)

Une classe par règle violée — dès le début, pas après

export class BookAlreadyBorrowedError extends DomainError {

constructor(bookId: BookId) {

super(

`Book ${bookId.value} is already borrowed`,

'BOOK_ALREADY_BORROWED'

);

}

✅ Bonnes pratiques

Code d'erreur lisible : BOOK_ALREADY_BORROWED
Message clair avec le contexte
Une erreur par règle métier

❌ À éviter

throw new Error("erreur") — trop générique
Une seule classe DomainError pour tout
Ajouter les erreurs à la fin du projet

L'interface du repository

Abstraite — l'implémentation vient demain dans adapters/

export interface BookRepository {

findById(id: BookId): Promise<Book | null>;

save(book: Book): Promise<void>;

findByIsbn(isbn: ISBN): Promise<Book | null>;

}

💡 Le repository ne parle qu'en termes du domaine (Book, BookId). Pas de BookEntity TypeORM ici.

Le use case complet

Orchestre : charge l'agrégat, appelle la méthode métier, sauvegarde

export class BorrowBook implements Usecase<BorrowBookInput, BorrowBookOutput> {

constructor(private bookRepo: BookRepository) {}

async execute(input: BorrowBookInput): Promise<BorrowBookOutput> {

// 1. Charger l'agrégat

const book = await this.bookRepo.findById(input.bookId);

if (!book) throw new BookNotFoundError(input.bookId);

// 2. Appeler la méthode métier (l'agrégat valide)

book.borrow(input.memberId);

// 3. Sauvegarder

await this.bookRepo.save(book);

// 4. Retourner le résultat

return { loanId: ..., dueDate: ... };

}

Tester le core/ sans base de données

Un InMemoryRepository suffit — on valide la logique métier, pas la persistance

export class InMemoryBookRepository implements BookRepository {

private books = new Map<string, Book>();

async findById(id: BookId) {

return this.books.get(id.value) ?? null;

}

async save(book: Book) {

const events = book.pullEvents();

// Rebuild simple : on stocke l'agrégat reconstruit

const restored = Book.restore(events);

this.books.set(book.id.value, restored);

}

💡 Si vos tests passent avec l'InMemoryRepository, ils passeront avec le repository PostgreSQL de demain. Le contrat est le même.

Pièges courants

❌ Importer des dépendances infrastructure dans core/

Pas de typeorm, inversify, express. Si vous en avez besoin, vous êtes dans le mauvais dossier.

⚠️ Oublier les DomainErrors

Ajoutez-les dès le début. Une règle métier sans erreur = un bug silencieux.

❌ Agrégats trop gros

Un agrégat = une responsabilité. Si Book gère aussi les loans, découpez.

⚠️ Mélanger apply() et logique métier

apply() mute l'état sans validation. La validation se fait dans la méthode métier (ex : borrow()).

À retenir !

✅ core/ ne dépend de RIEN d'externe — pas de TypeORM, pas d'Inversify ici.

✅ Les repositories sont des interfaces abstraites — l'implémentation vient demain.

✅ Pattern init/restore : init crée, restore rejoue l'historique.

✅ On peut tester le core/ sans base de données avec un InMemoryRepository.

✅ Ordre : événements → agrégat → value objects → erreurs → use cases.

Demain : on implémente adapters/ (TypeORM, mappers, Build) 🚀