Cas pratiques Monolith Refactoring

Contexte Une application Express rend une page HTML. Le Problème Le template appelle directement la base de données : <% const users = db.query("SELECT * FROM users") %> Contraintes Supprimer tout accès DB depuis la vue et déplacer la récupération des données dans le contrôleur. Livrable attendu Un flux MVC respecté avec séparation entre vue, contrôleur et accès aux données.

Contexte Un contrôleur encapsule toute la logique dans un unique try/catch. Le Problème Les erreurs métier et techniques sont mélangées et mal catégorisées. Contraintes Séparer la gestion des erreurs métier des erreurs système et retourner des codes HTTP adaptés. Livrable attendu Un contrôleur avec gestion d'erreurs structurée et claire.

Contexte Plusieurs routes répètent le même code d'authentification. Le Problème Chaque route contient : if (!req.headers.authorization) { return res.status(401).send(); } Contraintes Créer un middleware authMiddleware réutilisable et l'appliquer aux routes concernées. Livrable attendu Un code centralisant la logique d'authentification.

Contexte Un fichier utils.js contient 800 lignes avec fonctions diverses : formatDate, calculateTax, hashPassword, sendSMS. Le Problème Aucune organisation thématique ne permet de maintenir facilement le code. Contraintes Proposer un découpage logique en modules spécialisés par responsabilité. Livrable attendu Une nouvelle structure de fichiers cohérente améliorant lisibilité et maintenabilité.

Contexte Une application Node.js monolithique gère les utilisateurs dans un unique fichier userController.js. Le Problème La fonction createUser enregistre l'utilisateur ET envoie un email directement : async function createUser(req, res) { const user = await db.save(req.body); await sendEmail(user.email); res.json(user); } Contraintes Extraire la logique d'envoi d'email dans un module EmailService séparé sans modifier le comportement externe. Livrable attendu Un code refactoré séparant clairement la logique HTTP et la logique métier/email.

Contexte Un service métier contient des requêtes SQL inline. Le Problème La logique métier est couplée à la persistence. Contraintes Extraire les requêtes dans un module UserRepository distinct. Livrable attendu Un découplage clair entre logique métier et accès aux données.

Contexte Une route Express contient une logique métier complexe. Le Problème La route suivante mélange validation, calcul et réponse HTTP : app.post("/discount", (req, res) => { const total = req.body.total; const discount = total > 100 ? total * 0.1 : 0; res.json({ final: total - discount }); }); Contraintes Extraire la logique de calcul dans un service métier dédié. Livrable attendu Un code séparant clairement couche transport et logique métier.

Contexte Le projet contient : controllers/, models/, routes/, services/ sans distinction métier. Le Problème Les fichiers liés aux commandes et aux utilisateurs sont mélangés. Contraintes Proposer une restructuration par domaine : user/, order/, payment/ avec sous-dossiers internes. Livrable attendu Une arborescence claire améliorant la cohérence fonctionnelle.

Contexte Une variable globale currentUser est utilisée dans plusieurs modules. Le Problème Cela provoque des effets de bord imprévisibles. Contraintes Supprimer l'état global et passer les données explicitement via paramètres ou contexte. Livrable attendu Une version sans variable globale améliorant testabilité et fiabilité.

Contexte Deux fichiers orderService.js et paymentService.js s'importent mutuellement. Le Problème Node.js génère des objets partiellement initialisés provoquant des erreurs inattendues. Contraintes Casser la dépendance circulaire en introduisant une interface intermédiaire ou en déplaçant la responsabilité commune. Livrable attendu Un schéma ou code refactoré supprimant toute importation croisée.

Contexte Un objet cache global est utilisé dans toute l'application. Le Problème Les invalidations sont oubliées et provoquent des données obsolètes. Contraintes Encapsuler le cache dans un service dédié avec API explicite : get, set, invalidate. Livrable attendu Une abstraction de cache centralisée évitant les accès directs au store interne.

Contexte Toutes les erreurs sont capturées et renvoient status 500. Le Problème Les erreurs métier (validation, conflits) ne sont pas différenciées. Contraintes Mettre en place une hiérarchie d'erreurs personnalisées et un middleware centralisé. Livrable attendu Une gestion d'erreurs structurée distinguant erreurs métier et erreurs système.

Contexte Le module Reporting importe directement des modèles internes sensibles. Le Problème Toute modification métier casse les rapports. Contraintes Introduire des DTO dédiés ou interfaces de lecture pour isoler le module. Livrable attendu Une architecture réduisant le couplage entre reporting et domaine principal.

Contexte Les services métier contiennent des transactions SQL manuelles. Le Problème La logique transactionnelle est dupliquée dans plusieurs services. Code actuel await db.begin(); await db.insert(user); await db.insert(profile); await db.commit(); Contraintes Centraliser la gestion transactionnelle dans une couche Repository dédiée. Livrable attendu Un module Repository encapsulant begin/commit/rollback et simplifiant les services métier.

Contexte Un fichier ApplicationService.js contient la gestion des utilisateurs, commandes, paiements et reporting. Le Problème Toutes les responsabilités sont centralisées dans une seule classe de plus de 1200 lignes. Code actuel class ApplicationService { createUser() {} createOrder() {} processPayment() {} generateReport() {} } Contraintes Découper ce service en modules cohérents par domaine sans casser les routes existantes. Livrable attendu Une nouvelle organisation modulaire avec séparation claire des responsabilités et injection propre des dépendances.

Contexte Les constantes (URLs, secrets, ports) sont définies dans plusieurs fichiers. Le Problème La maintenance et le changement d'environnement sont risqués. Contraintes Centraliser la configuration dans un module unique utilisant variables d'environnement. Livrable attendu Un système de configuration centralisé propre et facilement extensible.

Contexte Une fonction calculatePrice contient de multiples if/else selon le type d'utilisateur. Le Problème Chaque nouveau type ajoute un bloc conditionnel supplémentaire. Code actuel if (type === "A") { ... } else if (type === "B") { ... } else if (type === "C") { ... } Contraintes Remplacer la logique conditionnelle par un pattern Strategy. Livrable attendu Une implémentation modulaire permettant d'ajouter un nouveau type sans modifier la fonction centrale.

Contexte Un traitement lourd bloque la boucle d'événements Node.js. Le Problème Le serveur ne répond plus pendant l'exécution. Code actuel const result = heavyComputation(); res.json(result); Contraintes Transformer le traitement en version asynchrone (Promise ou worker thread). Livrable attendu Un code non-bloquant préservant la réactivité du serveur.

Contexte Le projet suit un modèle MVC classique fortement couplé à Express. Le Problème La logique métier dépend directement des objets HTTP. Contraintes Repenser la structure interne pour isoler le domaine du framework web. Livrable attendu Une proposition de structure ports/adapters interne sans transformer en microservices.

Contexte OrderService dépend de PaymentService. PaymentService dépend de NotificationService. NotificationService dépend de OrderService. Le Problème Le chargement des modules provoque des objets incomplets et comportements imprévisibles. Contraintes Casser la boucle en introduisant une couche d'orchestration ou des interfaces abstraites. Livrable attendu Un schéma ou code restructuré supprimant toute dépendance circulaire.

Contexte Chaque route vérifie manuellement les rôles utilisateurs. Le Problème La logique d’autorisation est dupliquée et incohérente. Contraintes Centraliser l’autorisation via un middleware ou un module policy dédié. Livrable attendu Un système d’autorisation unifié évitant toute duplication et garantissant cohérence globale.

Contexte Un module utilise EventEmitter pour déclencher des événements internes. Le Problème Les listeners sont ajoutés à chaque requête sans être supprimés, provoquant une fuite mémoire. Code actuel emitter.on("data", handler); Contraintes Garantir la suppression ou réutilisation contrôlée des listeners afin d’éviter l’accumulation. Livrable attendu Une gestion sécurisée des abonnements empêchant toute fuite mémoire.

Contexte Le calcul de taxe est présent dans OrderService et InvoiceService. Le Problème Toute modification nécessite double mise à jour et crée risque d’incohérence. Contraintes Extraire la logique commune dans un module métier partagé cohérent. Livrable attendu Un service fiscal centralisé supprimant toute duplication.

Contexte Une création d’utilisateur effectue plusieurs inserts successifs. Le Problème En cas d’erreur intermédiaire, certaines données restent en base. Code actuel await db.insertUser(user); await db.insertProfile(profile); await db.insertSettings(settings); Contraintes Ajouter une gestion transactionnelle complète avec rollback automatique en cas d’échec. Livrable attendu Une implémentation robuste utilisant begin, commit et rollback garantissant l’atomicité.

Contexte Un monolithe Express gère commandes, paiements et notifications dans le même espace de code fortement couplé. Le Problème Le module Payment dépend directement des routes HTTP, des modèles ORM et de la configuration globale. Contraintes Isoler le domaine Payment en trois couches internes : - Domaine (logique métier pure) - Application (cas d’usage) - Infrastructure (ORM, HTTP) Aucune régression fonctionnelle n’est autorisée. Livrable attendu Une proposition de restructuration complète avec séparation claire des dépendances et inversion correcte des imports.

Contexte Un traitement lourd est exécuté directement dans le flux HTTP. Le Problème Les temps de réponse explosent et bloquent le serveur. Contraintes Introduire un mécanisme interne basé sur événements ou file en mémoire pour exécuter le traitement en différé. Livrable attendu Une architecture interne non bloquante séparant traitement long et réponse utilisateur.

Contexte Le monolithe contient des dossiers techniques (controllers, models, services) sans organisation métier. Le Problème Les responsabilités sont mélangées et les dépendances traversent tout le projet. Contraintes Restructurer l'application par domaines fonctionnels (User, Order, Payment) chacun avec ses sous-modules internes. Livrable attendu Une nouvelle arborescence cohérente réduisant le couplage inter-domaines.

Contexte Les entités métier contiennent des annotations et méthodes spécifiques à l’ORM. Le Problème Le domaine dépend entièrement de la technologie de persistence. Contraintes Découpler les entités métier des modèles ORM en introduisant un mapper ou adaptateur. Livrable attendu Une séparation claire entre entités métier et entités techniques de persistence.

Contexte Les variables d’environnement sont lues directement via process.env partout dans le code. Le Problème Les tests et environnements multi-stages deviennent imprévisibles. Contraintes Créer un module Configuration centralisé validant et normalisant les variables au démarrage. Livrable attendu Un système robuste garantissant cohérence et validation stricte de la configuration.

Contexte Un Logger global singleton est importé partout et modifie son comportement dynamiquement. Le Problème Les tests deviennent imprévisibles et l’état partagé provoque des effets de bord. Contraintes Remplacer le singleton par injection explicite de dépendance dans les modules consommateurs. Livrable attendu Une architecture sans état global partagé améliorant testabilité et isolation.