Le Use Case
Transformer les méthodes d'un service en classes individuelles. Un use case = un seul objectif, une seule méthode execute().
A curated collection of slide presentations and educational content.
Transformer les méthodes d'un service en classes individuelles. Un use case = un seul objectif, une seule méthode execute().
Restructurer l'API blog avec une architecture complète : domain/ (interfaces, modèles, use cases), infra/ (TypeORM, mappers), api/ (controllers). Tests pour chaque use case.
Formaliser le pattern Repository : interface dans le domaine, implémentation dans l'infrastructure. Comprendre pourquoi et où ranger chaque fichier.
Comprendre pourquoi l'entité de base de données est différente de l'objet métier. Formaliser le pattern Mapper avec toDomain() et fromDomain().
Donner des noms formels aux patterns qu'on utilise depuis des semaines : Controller, Use Case, Repository. L'étudiant reconnaît ses propres fichiers.
Prendre un controller monolithique qui fait tout (validation, logique, SQL) et le séparer en couches testables. Écrire les tests pour chaque couche.
Découvrir les 5 principes SOLID et réaliser qu'on les applique déjà : responsabilité unique (S8), interfaces fines (S10), dépendance aux abstractions (S11).
Comprendre que l'InMemoryRepository créé en S10 est un outil de test. L'injecter dans les services pour tester la logique métier sans base de données.
Maîtriser Jest avec describe, it, expect. Tester des fonctions pures avec différents matchers. Organiser ses tests proprement.
Comprendre le coût des bugs, découvrir les types de tests, et poser les bases des tests unitaires : tester la logique seule, sans serveur ni base de données.