Le climax architectural du programme
Aujourd'hui, tout ce qu'on a construit depuis la semaine 10 converge vers un seul moment : changer UNE ligne de code et voir toute l'architecture tenir.
1. Implémenter Repository<Article> avec PostgreSQL
CrĂ©er un PostgresArticleStorage qui respecte la mĂȘme interface.
2. Ăcrire un Mapper
Convertir entre ArticleEntity (TypeORM) et Article (domaine).
3. Constater que la logique métier ne change pas
Changer d'implĂ©mentation sans toucher au cĆur de l'application.
4. Comprendre la Dependency Inversion
Le D de SOLID, par la pratique â pas juste en thĂ©orie.
LE MOMENT
Résumé de tout ce qui a mené ici : S10 interfaces, S11 injection, S13 API, S14 SQL/TypeORM
Le Mapper
Convertir entre ArticleEntity et Article â toDomain / fromDomain
PostgresArticleStorage
Implémenter Repository<Article> avec TypeORM + Mapper
LA DĂMO EN LIVE
Changer UNE SEULE LIGNE dans main.ts â InMemory â PostgreSQL
Constater
Routes, service, logique â RIEN n'a changĂ©
Dependency Inversion
Nommer ce qu'on fait : le D de SOLID, Clean Architecture
Tout ce qu'on a construit depuis 4 semaines converge ici
Prenez une seconde. Respirez. Aujourd'hui, vous allez comprendre pourquoi on a fait tout ça.
Interfaces & Contrats
On a dĂ©fini Repository<Article> â une promesse, pas une implĂ©mentation
Injection de dépendances
On a injectĂ© l'interface, pas la classe â le service ne sait pas qui fait le travail
API REST & Express
Les routes utilisent le service, qui utilise l'interface â la chaĂźne est complĂšte
SQL, PostgreSQL & TypeORM
J1âJ4 : on a appris Ă parler Ă une vraie base de donnĂ©es
AUJOURD'HUI
On relie les deux bouts.
L'interface créée en S10 + la DB apprise en S14 = PostgresArticleStorage
đ
Interface
Le contrat
đ
Mapper
Le traducteur
đ
PostgreSQL
L'implémentation
C'est le contrat qu'on a écrit en S10. Il dit QUELLES méthodes existent, pas COMMENT elles fonctionnent.
export interface Repository<T> {
getAll(): Promise<T[]>;
getById(id: string): Promise<T | null>;
create(item: Omit<T, "id">): Promise<T>;
update(id: string, item: Partial<T>): Promise<T | null>;
delete(id: string): Promise<boolean>;
}
đĄ Cette interface ne mentionne ni SQL, ni tableau, ni base de donnĂ©es. C'est volontaire.
Notre implĂ©mentation actuelle â les donnĂ©es vivent dans un tableau en mĂ©moire.
export class InMemoryArticleStorage implements Repository<Article> {
private articles: Article[] = [];
async getAll(): Promise<Article[]> {
return this.articles;
}
async getById(id: string): Promise<Article | null> {
return this.articles.find(a => a.id === id) ?? null;
}
// ... create, update, delete
}
â ïž ProblĂšme : au redĂ©marrage du serveur, toutes les donnĂ©es disparaissent.
Le traducteur entre deux mondes
ArticleEntity
Le monde TypeORM
DĂ©corateurs, colonnes SQL, relations
Conçu pour la base de données
Article
Le monde du domaine
Objet pur, pas de décorateur
Conçu pour la logique métier
Convertir une ArticleEntity (TypeORM) en Article (domaine)
export class ArticleMapper {
static toDomain(entity: ArticleEntity): Article {
return new Article(
entity.id,
entity.title,
entity.content,
entity.authorId,
entity.createdAt,
entity.updatedAt,
);
}
}
đĄ Le domaine reçoit un objet propre, sans aucune trace de TypeORM.
Convertir un Article (domaine) en ArticleEntity (TypeORM)
export class ArticleMapper {
// ... toDomain()
static fromDomain(article: Article): ArticleEntity {
const entity = new ArticleEntity();
entity.id = article.id;
entity.title = article.title;
entity.content = article.content;
entity.authorId = article.authorId;
entity.createdAt = article.createdAt;
entity.updatedAt = article.updatedAt;
return entity;
}
}
đ Deux directions, une seule classe. Le Mapper est le gardien de la frontiĂšre.
Implémenter Repository<Article> avec TypeORM
La mĂȘme interface. La mĂȘme signature. Mais cette fois, les donnĂ©es persistent dans PostgreSQL.
export class PostgresArticleStorage implements Repository<Article> {
constructor(private repo: Repository<ArticleEntity>) {}
async getAll(): Promise<Article[]> {
const entities = await this.repo.find();
return entities.map(e => ArticleMapper.toDomain(e));
}
async getById(id: string): Promise<Article | null> {
const entity = await this.repo.findOneBy({ id });
return entity ? ArticleMapper.toDomain(entity) : null;
}
}
đ On rĂ©cupĂšre des ArticleEntity, on renvoie des Article. Le Mapper fait la traduction.
async create(data: Omit<Article, "id">): Promise<Article> {
const entity = ArticleMapper.fromDomain(new Article(crypto.uuid(), ...data));
const saved = await this.repo.save(entity);
return ArticleMapper.toDomain(saved);
}
async update(id: string, data: Partial<Article>): Promise<Article | null> {
const entity = await this.repo.findOneBy({ id });
if (!entity) return null;
Object.assign(entity, data);
const saved = await this.repo.save(entity);
return ArticleMapper.toDomain(saved);
}
async delete(id: string): Promise<boolean> {
const result = await this.repo.delete(id);
return result.affected > 0;
}
⥠Pattern : Entity â Mapper.fromDomain() â save â Mapper.toDomain() â Article
Le moment oĂč tout bascule
Ouvrez votre Ă©diteur. On va changer UNE SEULE LIGNE.
import { InMemoryArticleStorage } from "./adapters/InMemoryArticleStorage";
import { ArticleService } from "./core/ArticleService";
// Composition root
const storage = new InMemoryArticleStorage();
const service = new ArticleService(storage);
// Routes
app.get("/articles", (req, res) => {
const articles = await service.getAll();
res.json(articles);
});
â Les donnĂ©es disparaissent au redĂ©marrage
// â import { InMemoryArticleStorage } from "./adapters/InMemoryArticleStorage";
import { PostgresArticleStorage } from "./adapters/PostgresArticleStorage";
import { ArticleService } from "./core/ArticleService";
// Composition root
const storage = new PostgresArticleStorage(articleRepo);
const service = new ArticleService(storage);
// Routes â IDENTIQUES
app.get("/articles", (req, res) => {
const articles = await service.getAll();
res.json(articles);
});
UNE SEULE LIGNE A CHANGĂ
InMemoryArticleStorage â PostgresArticleStorage
Et maintenant, les donnĂ©es persistent. đ
Vérifions ce qui a changé⊠et ce qui n'a PAS changé
đŁïž
Routes
articleRoutes.ts
â Identique
âïž
Service
ArticleService.ts
â Identique
đŠ
Domaine
Article.ts
â Identique
đ
Interface
Repository<Article>
â Identique
đ§Ș
Tests
ArticleService.test.ts
â Identique
đ
main.ts
Composition root
⥠1 ligne changée
â Avant
const storage =
new InMemoryArticleStorage();
DonnĂ©es en mĂ©moire â perdues au redĂ©marrage
â AprĂšs
const storage =
new PostgresArticleStorage(repo);
DonnĂ©es en PostgreSQL â persistent toujours
Le service, les routes, le domaine, les tests â RIEN n'a bougĂ©.
C'est la preuve vivante que l'architecture tient.
Nommer ce qu'on vient de faire
Ce n'est pas juste un pattern. C'est un principe fondateur. Le D de SOLID.
S
Single Responsibility
O
Open/Closed
L
Liskov Substitution
I
Interface Segregation
D
Dependency Inversion
â Sans Inversion
Le service dépend d'une implémentation concrÚte (InMemoryArticleStorage)
â Changer de stockage = rĂ©Ă©crire le service
â Avec Inversion
Le service dépend d'une abstraction (Repository<Article>)
â Changer de stockage = changer 1 ligne
đĄ Les modules de haut niveau ne doivent pas dĂ©pendre des modules de bas niveau. Les deux doivent dĂ©pendre d'abstractions.
đŠ core/
Le cĆur de l'application
Article.ts â domaine
Repository.ts â interface
ArticleService.ts â logique
Ne connaßt PAS la base de données
đ adapters/
Les implémentations
InMemoryArticleStorage.ts
PostgresArticleStorage.ts
ArticleMapper.ts
ArticleEntity.ts
ConnaĂźt le core ET la DB
đ C'est exactement la structure de packages/iac/core/ vs packages/iac/adapters/ dans le codebase Bootcode.
â Passer trop vite
« Bon, on change l'implémentation, next. »
â Les Ă©tudiants ne rĂ©alisent pas l'importance de ce qu'ils viennent de faire
â Prendre le temps
« Regardez. UNE ligne. Et TOUT fonctionne encore. C'est CA, l'architecture. »
â Laisser le silence s'installer. Laisser la rĂ©vĂ©lation faire son effet.
C'est LE jour le plus important du programme. Prenez le temps.
â Interface couplĂ©e
interface ArticleStorage {
query(sql: string): any;
}
L'interface fuit l'implĂ©mentation SQL â impossible de changer
â Interface propre
interface Repository<T> {
getAll(): Promise<T[]>;
}
L'interface exprime le QUOI, pas le COMMENT â interchangeable
đĄ Les Ă©tudiants qui ont mal fait les interfaces en S10 auront du mal ici â aider individuellement.
â Raccourci dangereux
Utiliser ArticleEntity partout dans le service et les routes
â Le domaine est polluĂ© par les dĂ©corateurs TypeORM
â Impossible de changer de DB sans tout rĂ©Ă©crire
â L'investissement Mapper
Un fichier de plus, mais une frontiĂšre propre
â Le domaine reste pur et testable
â Changer d'ORM devient possible
Le Mapper est un investissement qui paie. Aujourd'hui vous le voyez.
Le jour le plus important du programme
1. Interface = contrat
Repository<Article> dit QUOI, pas COMMENT
2. Mapper = frontiĂšre
toDomain / fromDomain séparent les mondes
3. Adapter = bouchon
InMemory ou PostgreSQL, le service s'en fiche
4. 1 ligne = tout change
La composition root est le seul point de branchement
5. Dependency Inversion = le D de SOLID
DĂ©pendre d'abstractions, pas d'implĂ©mentations â vous l'avez VU aujourd'hui
« Changer d'implĂ©mentation sans toucher Ă la logique mĂ©tier, c'est pas de la magie â c'est de l'architecture. »
đ
Interface
Le contrat
đ
Mapper
Le traducteur
đ
Adapter
L'implémentation
Est-ce que tout est clair ? C'est normal si c'est dense â on en reparle.
N'hésitez pas à revoir le diff en live : seule l'instanciation change, tout le reste est identique.
1. Implémenter PostgresArticleStorage
Créer le fichier, implémenter les 5 méthodes de Repository<Article> avec TypeORM + Mapper.
2. Basculez en live
Changer la ligne dans main.ts. Redémarrer le serveur. Vérifier que les données persistent.
3. VĂ©rifiez le diff
Comparer les fichiers modifiés. Seul main.ts a changé ? Si non, pourquoi ?
4. Bonus : ajouter une relation
Ajouter un AuthorEntity avec une relation OneToMany vers ArticleEntity. Mettre Ă jour le Mapper.