# 🏗️ Layering & Bridging — Organiser en couches **Layering** = découper ton système en couches **Bridging** = créer les ponts entre ces couches > **Si tu ne sépares pas en couches, tout finit par dépendre de tout.** --- ## 🎯 Le principe ### Layering (Couches) Chaque couche a **une responsabilité claire** : - Présentation (UI) - Logique métier (Business) - Accès aux données (Data) ### Bridging (Ponts) Les couches communiquent via **des interfaces explicites**, pas directement. > 💡 **L'invariant** : "Une couche ne connaît que la couche directement en dessous" --- ## 🧠 Pourquoi c'est crucial ? Sans layering : - code spaghetti - impossible de tester - changement = catastrophe Avec layering : - **responsabilités claires** - **testabilité** (mock des couches) - **évolutivité** (change une couche sans toucher aux autres) - **compréhension** rapide --- ## 📊 Architecture en couches classique --- ## 🔍 Exemple concret ### ❌ Pas de layering ```ts // Controller mélangé avec DB app.get("/users/:id", async (req, res) => { const user = await db.query("SELECT * FROM users WHERE id = ?", [ req.params.id, ]); res.json(user); }); ``` **Problème** : La route dépend directement de la DB. Impossible de tester, impossible de changer de DB. --- ### ✅ Avec layering ```ts // 1. Data Layer (Repository) class UserRepository { async findById(id: string): Promise { return db.query("SELECT * FROM users WHERE id = ?", [id]); } } // 2. Business Layer (Use Case) class GetUserUseCase { constructor(private userRepo: UserRepository) {} async execute(userId: string): Promise { const user = await this.userRepo.findById(userId); if (!user) throw new NotFoundError(); return user; } } // 3. Presentation Layer (Controller) app.get("/users/:id", async (req, res) => { const getUser = new GetUserUseCase(userRepository); const user = await getUser.execute(req.params.id); res.json(user); }); ``` > 💡 **Les bridges** : > > - `UserRepository` = pont vers la DB > - `GetUserUseCase` = pont vers la logique métier > - `Controller` = pont vers le réseau --- { const products = await db.products.findAll(); res.json(products); });`, description: "Le controller saute la couche métier et va directement à la DB" }, problem: "Impossible d'ajouter de la logique métier, de valider, ou de tester unitairement", solution: "Toujours passer par la couche métier, même si elle semble 'vide' au début", goodExample: { code: `class GetProductsUseCase { async execute() { return this.productRepo.findAll(); } } app.get('/products', async (req, res) => { const useCase = new GetProductsUseCase(productRepo); const products = await useCase.execute(); res.json(products); });`, description: "Respect de la hiérarchie des couches" } }, { title: "Dépendances inversées (couche haute → couche basse)", badExample: { code: `// Business layer importe un controller class OrderService { createOrder(data: OrderDTO) { // ... sendToController(orderData); // ❌ Dépendance vers le haut } }`, description: "La couche métier dépend de la couche présentation" }, problem: "Architecture à l'envers : impossible de réutiliser la logique métier sans le controller", solution: "Utiliser des events ou callbacks, jamais d'import direct vers le haut", goodExample: { code: `class OrderService { constructor(private eventBus: EventBus) {} createOrder(data: OrderDTO) { // ... this.eventBus.emit('order.created', order); // ✅ Découplé } }`, description: "La couche métier émet un event, la présentation l'écoute" } }, { title: "Bridges trop couplés", badExample: { code: `interface UserRepository { // ❌ Expose des détails de l'ORM findByIdWithRelations(id: string, relations: string[]): Promise; }`, description: "L'interface du bridge fuit des détails d'implémentation" }, problem: "Changer d'ORM = changer l'interface = casser toute la couche métier", solution: "Les bridges doivent abstraire complètement l'implémentation", goodExample: { code: `interface UserRepository { // ✅ Abstrait, indépendant de l'ORM findById(id: string): Promise; findWithOrders(id: string): Promise; }`, description: "Interface métier, pas technique" } } ]} /> --- ## 🧪 Les 3 niveaux de layering ### 1. **Physical Layering** (fichiers/dossiers) ``` src/ presentation/ # Controllers, views business/ # Use cases, domain data/ # Repositories, DB ``` ### 2. **Logical Layering** (dépendances) ```ts // ✅ Bon : haut → bas import { UserRepository } from "../data/UserRepository"; // ❌ Mauvais : bas → haut import { UserController } from "../presentation/UserController"; ``` ### 3. **Runtime Layering** (flux d'exécution) ``` Request → Controller → Use Case → Repository → DB ← ← ← ← ``` --- --- --- ## 🗺️ Carte mentale de synthèse --- ## 🚀 Résultat attendu En maîtrisant le layering et bridging, tu deviens capable de : - **Structurer** n'importe quel projet proprement - **Tester** chaque couche indépendamment - **Changer** une technologie sans tout casser - **Comprendre** l'architecture en un coup d'œil Et surtout : Tu construis des systèmes où **changer une couche n'impacte pas les autres**. Le layering, c'est ton plan d'urbanisme logiciel.