Aller au contenu

Semaine 6 : JOUR 4 - ARCHITECTURE MVC VS ARCHITECTURE HEXAGONALE

Formation Java / Spring Boot – Vision architecturale avancée

Journée purement informative

Objectifs

À l’issue de cette journée, vous sevez capable de :

Lien vers un cours complet avec un exemple pratique à réaliser

1) Architecture MVC (modèle Spring Boot classique)

Structure utilisée dans vos projets :

controller/
service/
repository/
domain/ ou model/
dto/

Flux :

Controller → Service → Repository → Database

2) Avantages de MVC

3) Limites observées

  1. Le service dépend du repository
  2. Le repository dépend de JPA
  3. Le domaine dépend de Spring
  4. Les tests nécessitent souvent Spring

Le domaine est couplé à la technique.

PARTIE 2 – PROBLÈME FONDAMENTAL

Question clé

Si demain :

Que devient votre logique métier ?

Elle est en partie prisonnière du framework.

PARTIE 3 – INTRODUCTION À L’ARCHITECTURE HEXAGONALE

Si cela vous êtes intéresse et si nous avons le temps, j’ai un cours complet sur cette architecture que nous pourrons aborder avec des exemples de code.

1) Définition

Architecture hexagonale (Alistair Cockburn) :

Le cœur du métier ne dépend d’aucune technologie.

Par conséquent, on utilise des Ports et des Adapters

2) Principe fondamental

Le domaine est au centre et les technologies sont autour.

          [ REST ]
              |
 [ MQ ] — [ CORE ] — [ DB ]
              |
           [ CLI ]

3) Concept clé : inversion des dépendances

Comme vous maitrisez la notion d’interface, tout devient limpide et simple…

Dans MVC : Service → Repository concret

Dans Hexagonale, c’est différent :

PARTIE 4 – STRUCTURE HEXAGONALE

1) Nouvelle organisation

domain/
  ├── model/
  ├── port/
application/
  ├── usecase/
infrastructure/
  ├── persistence/
  ├── mq/
  ├── web/

2) Domaine pur

Exemple :

public interface CompteRepositoryPort {
    Option<Compte> findByNumero(String numero);
    void save(Compte compte);
}

Ici, aucune dépendance Spring.

3) Use Case (le cœur applicatif)

public class VirementUseCase {

    private final CompteRepositoryPort repository;

    public VirementUseCase(CompteRepositoryPort repository) {
        this.repository = repository;
    }

    public Either<String, Void> virer(...) {
        ...
    }
}

4) L’Adapter JPA (infrastructure)

@Repository
public class CompteRepositoryAdapter
    implements CompteRepositoryPort {

    private final SpringDataCompteRepository jpaRepo;

    @Override
    public Option<Compte> findByNumero(String numero) {
        return Option.ofOptional(jpaRepo.findByNumero(numero));
    }
}

5) Adapter REST

@RestController
public class VirementController {

    private final VirementUseCase useCase;

    @PostMapping("/virement")
    public ResponseEntity<?> virer(...) {
        ...
    }
}

PARTIE 5 – COMPARAISON MVC et HEXAGONALE

1) Dépendances

MVC

Dépendance descendante forte.

Controller → Service → Repository → JPA → PostgreSQL

Hexagonale

Le domaine ne dépend de rien.

Controller → UseCase ← RepositoryAdapter

2) Testabilité

3) Évolutivité

4) Complexité

PARTIE 6 – REFLEXION

Pourquoi les banques utilisent souvent une architecture proche de l’hexagonale ?

La raison est que le domaine métier doit survivre aux frameworks !

PARTIE 7 – TP GUIDÉ : REFLEXION ARCHITECTURALE

Exercice 1 – Identifier les dépendances

Dans votre projet actuel :

Exercice 2 – Extraire un Port

Créer :

public interface AuditPort {
    void enregistrer(VirementEvent event);
}

Implémenter :

@Component
public class RabbitAuditAdapter implements AuditPort

Modifier le UseCase pour dépendre du Port.

Exercice 3 – Simuler un changement technique

Remplacer RabbitMQ par une implémentation console. Aucune modification dans le UseCase.

PARTIE 8 – LIMITES DE L’HEXAGONALE

SYNTHÈSE

Vous savez maintenant :

TRANSITION

Les derniers jours on pourra aborder :

Vous êtes désormais des développeur.euse.s confirmés.

```