Module 14 – Architecture hexagonale (optionnelle, expliquée)

1. Pourquoi parler d’architecture ?

Au début, un projet est petit :

• 5 classes
• tout est simple

Puis :

• nouvelles features
• nouveaux développeurs
• pression du métier

Sans structure, le projet devient fragile.

---

2. Problème du “tout Spring partout”

Quand le domaine dépend directement de Spring/JPA :

• tests métier compliqués
• migration techno difficile
• logique métier mélangée à l’infra

---

3. Principe hexagonal (image mentale)

Le métier au centre (le “domaine”). Autour : des adaptateurs.

[ Web/API ] -> [ Application ] -> [ Domaine ] <- [ DB/JPA ]

• Ports = interfaces (contrats)
• Adaptateurs = implémentations techniques

---

4. Exemple sur Wouaf Wouaf (port repository)

Port :

public interface ChienStore {
  Chien save(Chien chien);
  Optional<Chien> findByTatouage(String tatouage);
}

Adaptateur JPA :

@Repository
public class ChienJpaStore implements ChienStore {

  private final ChienRepository repo;

  public ChienJpaStore(ChienRepository repo) { this.repo = repo; }

  @Override
  public Chien save(Chien chien) { return repo.save(chien); }

  @Override
  public Optional<Chien> findByTatouage(String tatouage) {
    return repo.findByNumeroTatouage(tatouage);
  }
}

Service métier dépend du port :

public class RegisterChienUseCase {

  private final ChienStore store;

  public RegisterChienUseCase(ChienStore store) { this.store = store; }

  public void register(...) { ... }
}

---

5. Avantages / coûts

✅ tests faciles (mock du port)
✅ domaine “pur”
❌ plus de fichiers
❌ nécessite discipline

---

6. Quand l’utiliser ?

• projet long terme
• plusieurs équipes
• besoin de testabilité

Si petit projet pédagogique : optionnelle.

---

7. Mini-exercices

1. Extraire le port RaceStore.
2. Tester un use-case sans Spring.