Formation Spring Boot – Support complet et pédagogique (Projet Wouaf Wouaf)

But : apprendre à construire une API REST comme en entreprise, pas juste “faire un tuto”.

---

0.1 Ce que vous allez savoir faire à la fin

Vous saurez :

1. Concevoir un modèle métier avec UML (avant de coder)
2. Coder une API REST Spring Boot : controllers, services, repositories
3. Protéger l’API : validation, erreurs, sécurité (rôles, JWT)
4. Tester sérieusement : unitaires + intégration + sécurité + DB réelle (Testcontainers)
5. Industrialiser : monitoring (Actuator), Docker, CI/CD, Kubernetes
6. Structurer votre projet pour qu’il reste maintenable (Hexagonale / Clean en option)

---

0.2 Pourquoi on s’appuie sur un projet fil rouge (Wouaf Wouaf)

Si on n’utilise que des exemples “jouets”, on comprend la syntaxe… mais on ne comprend pas :

• comment les couches s’organisent,
• où mettre les règles,
• comment éviter le code spaghetti,
• comment tester une vraie application.

Wouaf Wouaf donne un cadre concret :

• Race : référentiel
• Chien : entité principale (règles + recherche)
• Proprietaire : relationnel + validation
• Concours + inscriptions : workflow métier (états, contraintes)

---

0.3 Comment lire ce support

Chaque module suit le même fil (important) :

1. Problème (dans la vraie vie)
2. Objectif (ce qu’on veut obtenir)
3. UML (clarifier avant d’écrire du Java)
4. Implémentation (code + explications pas-à-pas)
5. Tests (comment vérifier que ça marche vraiment)
6. Pièges (les erreurs qui coûtent cher)
7. Mini-exercices (pour ancrer)

---

0.4 Architecture cible (et pourquoi)

Pourquoi séparer Controller / Service / Repository ?

Parce que chaque couche a une responsabilité claire :

• Controller : parle HTTP (JSON, codes HTTP, validation des entrées)
• Service : parle métier (règles, enchaînements, transactions)
• Repository : parle base de données (requêtes, pagination, tri)

Si on mélange :

• le controller devient un “super-cerveau” impossible à tester,
• les règles métier se dispersent,
• les bugs deviennent “fantômes”.

---

0.5 UML : l’arme anti-bugs (oui oui)

UML ne sert pas à “faire joli”. Il sert à éviter de coder une erreur de conception.

Diagramme de classes : “Quelles données ? Quelles relations ?”

Ex : Race 1 ---- * Chien (une race a plusieurs chiens)

Diagramme de séquence : “Qui appelle qui ?”

Ex : Inscrire un chien : Controller → Service → Repo (Concours) → Repo (Chien) → Repo (Inscription)

Diagramme d’activités : “Quel est le processus ?”

Ex : inscription :

• concours ouvert ?
• chien pas déjà inscrit ?
• chien pas retiré ?

---

0.6 Règles de qualité (à appliquer toute la formation)

• Jamais exposer une @Entity directement dans l’API → DTO
• Jamais mettre une règle métier dans un controller → Service
• Toujours un format d’erreur stable → ControllerAdvice
• Toujours tester au moins :
  • 1 règle métier importante (unitaire)
  • 1 endpoint critique (intégration)
  • 1 règle de sécurité (sécurité)

---

0.7 Commandes utiles (Maven)

# compiler
mvn compile

# lancer tests
mvn test

# packager
mvn clean package

# lancer l'app
mvn spring-boot:run

---

0.8 Mini-exercices

1. Expliquez la différence Controller/Service/Repository avec vos mots.
2. Donnez un exemple de règle métier qui ne doit PAS être dans un controller.
3. Dessinez un mini diagramme de séquence pour “créer un chien”.