Clean Architecture — Concevoir des applications durables et testables

Formation créée le 03/04/2026.
Version du programme : 1

Type de formation

Présentiel

Durée de formation

21 heures (3 jours)
Cette formation est gratuite.
S'inscrire
Cette formation est gratuite.
S'inscrire
Cette formation est gratuite.
S'inscrire

Clean Architecture — Concevoir des applications durables et testables


Objectif de formation : Permettre aux développeurs expérimentés de maîtriser les principes et patterns de la Clean Architecture — SOLID, séparation des couches, inversion des dépendances, ports et adaptateurs, use cases — afin de concevoir des applications indépendantes des frameworks, testables, maintenables et évolutives, quelle que soit la technologie utilisée. Un projet applicatif fil rouge agnostique (système de gestion de commandes) est développé et refactorisé progressivement tout au long de la formation — de l'analyse des problèmes d'une architecture monolithique couplée jusqu'à une implémentation complète en Clean Architecture avec tests — dans le langage de prédilection des participants.

Objectifs de la formation

  • Comprendre les problèmes structurels des architectures traditionnelles (N-tiers, MVC couplé)
  • Maîtriser les 5 principes SOLID et les appliquer concrètement dans du code réel
  • Comprendre les 4 couches de la Clean Architecture et la règle de dépendance
  • Implémenter des Entities, Use Cases, Ports et Adapters correctement
  • Appliquer l'architecture hexagonale (Ports & Adapters) comme mise en œuvre concrète
  • Écrire des tests unitaires isolés des dépendances externes grâce à l'inversion de dépendances
  • Refactoriser un code existant couplé vers une Clean Architecture progressive
  • Positionner CQRS et DDD comme extensions naturelles de la Clean Architecture

Profil des bénéficiaires

Pour qui
  • Développeurs expérimentés souhaitant structurer leurs applications de manière durable et maintenable
  • Tech leads et architectes logiciels souhaitant définir des standards d'architecture pour leur équipe
  • Développeurs confrontés à de la dette technique et souhaitant refactoriser progressivement
  • Toute personne engagée dans une démarche Software Craftsmanship
Prérequis
  • Expérience significative en développement orienté objet (minimum 2 ans)
  • Maîtrise d'au moins un langage orienté objet : Java, C#, TypeScript, Python, PHP ou équivalent
  • Notions de base sur les tests unitaires souhaitées

Contenu de la formation

Module 1 — Pourquoi la Clean Architecture ? Problèmes et principes fondateurs (3h)
  • L'état réel des codebases en entreprise : couplage fort, dette technique, tests impossibles
  • Les architectures traditionnelles et leurs limites : Architecture N-tiers (3-couches), MVC couplé au framework, Le Big Ball of Mud
  • Genèse de la Clean Architecture : Robert C. Martin (Uncle Bob), influences de l'architecture hexagonale (Alistair Cockburn) et de l'Onion Architecture (Jeffrey Palermo)
  • La promesse de la Clean Architecture : indépendance du framework, indépendance de l'UI, indépendance de la base de données, testabilité
  • La règle fondamentale : la règle de dépendance — les cercles intérieurs ne savent rien des cercles extérieurs
  • Screaming Architecture : pourquoi votre architecture doit "crier" le domaine métier, pas le framework
  • Panorama des architectures connexes : Hexagonale, Onion, Vertical Slice — convergences et différences
  • Travaux pratiques : analyse collective d'une codebase couplée (projet fil rouge en état initial) — identification des problèmes : couplage UI/domaine, dépendances directes aux frameworks, impossibilité d'écrire des tests unitaires ; constitution du diagnostic architectural
Module 2 — Principes SOLID : fondation théorique et application pratique (4h)
  • S — Single Responsibility Principle (SRP) : une classe, une raison de changer — détecter les violations, refactoriser
  • O — Open/Closed Principle (OCP) : ouvert à l'extension, fermé à la modification — stratégies, décorateurs
  • L — Liskov Substitution Principle (LSP) : les sous-types doivent être substituables — erreurs classiques en héritage
  • I — Interface Segregation Principle (ISP) : des interfaces cohésives et focalisées — éviter les interfaces "fourre-tout"
  • D — Dependency Inversion Principle (DIP) : dépendre des abstractions, pas des implémentations — le principe central de la Clean Architecture
  • Anti-patterns SOLID courants : God Class, Feature Envy, Shotgun Surgery, Primitive Obsession
  • Object Calisthenics : les 9 règles pratiques pour écrire un code objet de qualité
  • SOLID et Clean Architecture : comment chaque principe contribue à la règle de dépendance
  • Travaux pratiques : kata de refactoring en 3 rounds — les participants reçoivent un extrait de code violant les 5 principes SOLID, les identifient un par un et les corrigent progressivement ; chaque correction améliore la testabilité et réduit le couplage du projet fil rouge
Module 3 — Les 4 couches de la Clean Architecture (4h)
  • Couche Entities (Domaine) : les règles métier de l'entreprise — ce qui ne change jamais quelle que soit l'interface ou la base de données
  • Couche Use Cases (Application) : les cas d'utilisation de l'application — les règles métier spécifiques à l'application
  • Couche Interface Adapters : convertir les données entre le format des Use Cases et le monde extérieur
  • Couche Frameworks & Drivers : les détails — base de données, web framework, UI, services tiers
  • Travaux pratiques : implémentation complète d'un premier Use Case sur le projet fil rouge — création de l'entité, du Value Object associé, du Use Case avec Input/Output Port, du Controller et du Gateway — sans aucune dépendance au framework dans les couches internes
Module 4 — Architecture Hexagonale : Ports & Adapters en pratique (4h)
  • L'architecture hexagonale (Alistair Cockburn 2005) : relation avec la Clean Architecture
  • Ports : les interfaces définissant les contrats — Ports primaires (driven) vs Ports secondaires (driving)
  • Adaptateurs : les implémentations concrètes des ports
  • Inversion de dépendances en pratique : l'injection de dépendances comme mécanisme d'implémentation du DIP
  • Adaptateurs In-Memory pour les tests : tester la logique métier sans base de données ni services externes
  • Anti-Corruption Layer (ACL) : protéger le domaine des modèles externes corrompus
  • Travaux pratiques : ajout de 3 adaptateurs au projet fil rouge — un adaptateur REST (port primaire), un adaptateur de persistance In-Memory (port secondaire pour les tests) et un adaptateur de base de données réelle (port secondaire de production) ; démonstration de la substitution d'un adaptateur par un autre sans toucher au domaine
Module 5 — Tests, refactoring et migration vers la Clean Architecture (4h)
  • Stratégie de tests dans une Clean Architecture : Tests unitaires isolés : tester les Use Cases avec des adaptateurs In-Memory Tests d'intégration : tester les adaptateurs secondaires (persistence, API externes) Tests end-to-end : valider les flux complets via les ports primaires La pyramide de tests : quelle couche teste quoi et pourquoi
  • Test-Driven Development (TDD) en Clean Architecture : commencer par les ports, laisser l'architecture émerger
  • Refactoring progressif d'un legacy vers la Clean Architecture : Stratégie des "Strangler Fig" : ne pas tout réécrire, envelopper progressivement Identifier les Use Cases cachés dans le code existant Extraire le domaine du couplage : étape par étape sans casser la production Mesurer les progrès : testabilité, couplage, cohésion
  • Introduction à CQRS comme extension naturelle des Use Cases : séparer Command et Query au niveau de l'architecture
  • Panorama DDD (Domain-Driven Design) : Aggregates, Bounded Contexts, Domain Events — comment ils s'articulent avec la Clean Architecture
  • Travaux pratiques : session de refactoring du projet fil rouge — migration d'un Use Case couplé vers la Clean Architecture avec la stratégie Strangler Fig ; écriture de la suite de tests unitaires couvrant le domaine et les Use Cases ; démonstration que les tests passent avant et après le refactoring
Module 6 — Architecture en équipe, standards et pérennité (2h)
  • Définir et documenter les standards d'architecture de son équipe : ADR (Architecture Decision Records)
  • Comment faire adopter la Clean Architecture par une équipe : onboarding, conventions, revues de code
  • Garder l'architecture propre dans le temps : automatiser les règles d'architecture avec ArchUnit (Java), NetArchTest (.NET)
  • Identifier les violations d'architecture automatiquement dans la CI/CD
  • Quand ne pas utiliser la Clean Architecture : cas d'usage simples, CRUD purs, projets courts
  • Vertical Slice Architecture : une alternative pragmatique pour certains contextes
  • La Clean Architecture et les microservices : chaque service comme une Clean Architecture indépendante
  • Plan d'action individuel : chaque participant définit les 3 prochaines étapes concrètes à appliquer sur son projet réel
  • Travaux pratiques : écriture d'un ADR (Architecture Decision Record) pour le projet fil rouge, configuration d'une règle d'architecture automatisée dans la CI (exemple avec ArchUnit ou équivalent), présentation croisée des plans d'action individuels

Équipe pédagogique

Professionnel expert technique et pédagogique.