Objectifs du chapitre

• Identifier et comparer les principaux styles architecturaux utilisés dans le développement d’applications d’entreprise.
• Distinguer les architecture patterns (Layered, MVC, Event-Driven) et les appliquer dans un contexte Spring Boot.
• Identifier les patterns qui seront utilisés concrètement dans le framework Spring tout au long du module.

Prérequis :

• Bonne maîtrise de la programmation orientée objet en Java.
• Connaissance des concepts de base UML (diagramme de classes).
• Notions de base en développement web (client/serveur).

1. Horaires et évaluation

Le module dure 42 heures, soit 14 séances de 3 heures. Chaque séance se découpe en 1h30, pause de 15 min, puis 1h30.

La moyenne finale se calcule ainsi : contrôle continu × 60% + examen écrit (en fin de module) × 40%.

2. Qu’est-ce qu’un système d’information ?

Un système d’information (SI) est un ensemble organisé de ressources (personnes, matériel, logiciels, données, procédures) permettant d’acquérir, traiter, stocker, communiquer et diffuser de l’information au sein d’une organisation.

Le SI ne se réduit pas à l’informatique : il englobe l’organisation, le système informatique n’en est que le support technique.

Rôle et enjeux

Le cycle de vie d’un logiciel

À l’intérieur du SI, chaque application suit son propre cycle de développement, en sept phases :

1. Expression des besoins
2. Analyse
3. Conception
4. Développement
5. Tests
6. Déploiement
7. Maintenance

La documentation accompagne tout le cycle de vie du SI : elle garantit la traçabilité des décisions, facilite la maintenance et assure la continuité des connaissances entre les équipes.

Le choix du modèle de cycle de vie dépend du niveau d’incertitude et du besoin de livraisons rapprochées.

3. Pourquoi architecturer ?

Sur une application web de livraison, plusieurs questions se posent dès le départ :

• Comment séparer les responsabilités entre les différentes parties de l’application ?
• Comment organiser le code pour qu’il reste maintenable ?
• Comment faire évoluer l’application sans tout réécrire ?

La réponse passe par le choix d’une architecture logicielle adaptée.

4. Styles architecturaux

Un style architectural est un ensemble de principes et de contraintes qui définissent la structure globale d’un système logiciel : comment ses composants sont organisés, comment ils communiquent et comment les responsabilités sont réparties.

Une mauvaise architecture ne se voit pas immédiatement, elle se paie plus tard sous forme de dette technique : l’objectif est d’anticiper dès la conception. Sans architecture définie :

• Le code devient difficile à maintenir et à faire évoluer.
• Les responsabilités se mélangent (logique métier, accès aux données, interface…).
• Les pannes se propagent à l’ensemble du système.
• Le travail en équipe devient difficile à coordonner.

On distingue principalement quatre styles : monolithique (une seule application, un seul déploiement), SOA (services orchestrés autour d’un bus, l’ESB), microservices (services autonomes déployés indépendamment) et événementiel (communication asynchrone par événements).

Architecture monolithique

Un monolithe est une application dans laquelle toutes les fonctionnalités sont regroupées et déployées en une seule unité indivisible (la logique métier, l’accès aux données et l’exposition des services cohabitent dans le même bloc applicatif).

L’intégralité du backend est un seul projet Spring Boot, compilé et déployé en un unique fichier JAR. Il est structuré en trois couches logiques superposées (présentation avec @RestController, service avec @Service, accès aux données avec @Repository) qui partagent une base de données unique, avec un schéma commun à tous les modules.

Avantages :

• Simple à développer et déployer au départ.
• Facile à déboguer et tester en local.
• Pas de complexité de communication entre composants.
• Un seul projet backend à gérer et à versionner.

Inconvénients :

• Un bug dans un module peut faire tomber tout le backend.
• Scalabilité globale uniquement, impossible de scaler un seul module.
• Plus l’application grandit, plus le code devient difficile à maintenir.
• Le déploiement d’une petite modification nécessite de redéployer tout le backend.
• Le travail en équipe devient compliqué sur un seul et même projet.

SOA (Service Oriented Architecture)

L’architecture SOA découple les fonctionnalités métier en services autonomes, chacun encapsulant une capacité métier précise (facturation, gestion des commandes, authentification, etc.).

Chaque service :

• expose une interface standardisée (souvent via des contrats WSDL/SOAP ou des API REST) ;
• est autonome dans son exécution et son cycle de vie ;
• est réutilisable par plusieurs applications ou processus métier ;
• communique avec les autres services sans connaissance de leur implémentation interne (principe de faible couplage).

Les quatre principes clés (piliers SOA) :

L’ESB (Enterprise Service Bus) est la pièce maîtresse qui transforme un ensemble de services en une véritable architecture SOA cohérente :

Microservices

L’architecture Microservices décompose le backend en services autonomes et indépendants, chacun gérant un contexte métier précis, disposant de sa propre base de données et pouvant être déployé indépendamment des autres.

Contrairement au monolithe où tout est regroupé dans un seul JAR, chaque microservice est un projet à part entière, avec son propre cycle de vie. Les services communiquent par des appels HTTP/REST ou des messages asynchrones.

Un API Gateway joue le rôle de point d’entrée unique : il reçoit toutes les requêtes du frontend et les route vers le bon microservice.

Sur l’exemple de la livraison :

• Le client (navigateur ou mobile) passe en HTTPS par l’API Gateway (point d’entrée unique, routage, authentification, load balancing).
• Eureka est le Service Registry : l’annuaire dynamique où les microservices s’enregistrent (Service Discovery).
• Chaque microservice est un projet Spring Boot avec sa propre base : Commandes (port 8081, MySQL), Livreurs (8082, MySQL), Restaurants (8083, MongoDB), Paiement (8084, PostgreSQL).
• Entre services, la communication est synchrone en HTTP/REST, ou asynchrone via un message broker (RabbitMQ, Kafka).

Avantages :

• Scalabilité fine, on scale uniquement le service surchargé.
• Déploiement indépendant de chaque service.
• Résilience, une panne n’impacte pas tout le système.
• Équipes autonomes par service.
• Technologie libre par service.

Inconvénients :

• Complexité opérationnelle élevée (Docker, Kubernetes).
• Communication réseau entre services avec latence.
• Gestion distribuée des transactions complexe.
• Multiplication des bases de données à gérer.
• Monitoring et debug distribués difficiles.

Event-Driven (orienté événements)

Dans une architecture Event-Driven, les composants ne communiquent pas directement entre eux : un composant publie un événement, et les autres composants intéressés réagissent à cet événement de manière indépendante.

Ce découplage est l’avantage fondamental : le producteur d’un événement ne connaît pas les consommateurs, et les consommateurs ne connaissent pas le producteur.

Exemple : CommandeService ne connaît pas les services qui réagissent, il se contente de publier l’événement CommandePassée. Simultanément et indépendamment, le restaurant est notifié, un livreur est cherché, un email de confirmation est envoyé et le stock est mis à jour. Personne n’attend personne, tout se passe en parallèle.

Sans événements, CommandeService doit connaître tous les services qu’il appelle (Notification, Livreur, Stock) et il faut le modifier à chaque service ajouté (couplage fort).

Tableau comparatif des 4 styles

5. Architecture Patterns

Style architectural ou patron d’architecture ?

Analogie : le style architectural est le plan d’urbanisme d’une ville (quartiers, routes principales), le patron d’architecture est le plan d’un bâtiment précis à l’intérieur d’un quartier.

Les trois familles de patrons d’architecture

Tout patron d’architecture répond à l’une de ces trois questions : comment organiser les composants, comment les faire communiquer, ou comment organiser la logique applicative ?

Le patron MVC (Model, View, Controller)

Le principe est de séparer les données (Modèle), l’affichage (Vue) et la logique de commande (Contrôleur) pour faire évoluer chacun indépendamment.

• Le Modèle (Model) porte les données et la logique métier ; il ne connaît ni la Vue ni le Contrôleur.
• La Vue (View) affiche l’état du modèle à l’utilisateur, sans contenir de logique métier.
• Le Contrôleur (Controller) reçoit les actions de l’utilisateur, met à jour le modèle, puis choisit la vue à afficher.
• Un même Modèle peut être observé par plusieurs Vues (pattern Observer), synchronisées automatiquement.

Avantages :

• Séparation claire des responsabilités : données, logique métier et présentation évoluent indépendamment.
• Une même Vue peut être remplacée (web, mobile, API) sans toucher au Modèle ni au Contrôleur.
• Facilite les tests unitaires : Modèle et Contrôleur sont testables sans interface graphique.
• Pattern largement répandu : onboarding rapide, nombreux frameworks prêts à l’emploi.

Limites : sur des interfaces très interactives (SPA complexes), le Contrôleur peut devenir un point de passage surchargé (« Fat Controller ») et la frontière Vue/Contrôleur se brouille, d’où l’émergence de variantes comme MVVM ou MVP.

L’architecture en couches (Layered)

L’architecture en couches divise une application en groupes distincts de responsabilités superposés, chaque couche communiquant uniquement avec celle qui la suit, ce qui garantit une séparation claire des préoccupations, une meilleure maintenabilité et la réutilisation du code.

Chaque couche ne dépend que de la couche immédiatement inférieure. Cette règle apporte trois bénéfices :

• Isoler les changements : modifier la base de données n’impacte pas les contrôleurs.
• Faciliter les tests : tester la couche Service sans base de données réelle (séance 10).
• Clarifier les responsabilités de chaque classe du projet.

Les trois couches principales :

CQRS (Command Query Responsibility Segregation)

• Une Command modifie l’état du système (créer, modifier, annuler…) et ne retourne pas de données métier, juste une confirmation.
• Une Query lit l’état du système et ne le modifie jamais, aucun effet de bord.
• Le modèle d’écriture peut rester normalisé et strict (garant des règles métier), pendant que le modèle de lecture est dénormalisé et optimisé pour l’affichage.
• Les deux modèles peuvent même vivre dans des bases différentes, synchronisées de façon asynchrone (cohérence à terme).

Le Command handler valide et applique la règle métier sur le modèle d’écriture (base normalisée), le Query handler n’applique aucune règle métier et lit le modèle de lecture (vue dénormalisée). Les deux sont reliés par une synchronisation, immédiate ou différée.

Exemple : sur une plateforme de e-commerce, la commande « Passer une commande » écrit dans une base transactionnelle stricte, pendant que le catalogue produit consulté par des millions de visiteurs est lu depuis un cache ou une base dénormalisée dédiée à l’affichage.

Le patron Hexagonal (Ports & Adapters)

• Le domaine métier (le « cœur ») ne dépend d’aucune technologie : ni base de données, ni framework web, ni file de messages.
• Les ports sont des interfaces définies par le domaine : ce dont il a besoin (port sortant, ex. sauvegarder) ou ce qu’il propose (port entrant, ex. réserver un véhicule).
• Les adaptateurs implémentent ces ports avec une technologie concrète : un contrôleur REST, un repository JPA, un client de messagerie…
• On peut ainsi remplacer un adaptateur (ex. passer de MySQL à MongoDB) sans modifier une seule ligne du domaine.

6. Qu’est-ce qu’un framework ?

Une bibliothèque (library) est une boîte à outils que vous utilisez à votre initiative, sans qu’elle vous impose de structure (c’est votre code qui décide quand y faire appel, vous gardez la main sur le déroulement du programme), par exemple une bibliothèque de calcul de dates.

Un framework est un cadre qui impose sa propre structure et prend le contrôle du déroulement de l’exécution (ce n’est plus vous qui appelez le code, c’est le framework qui appelle le vôtre, au moment où il le juge nécessaire, et vous remplissez les points d’extension qu’il définit).

Le principe Hollywood, « Don’t call us, we’ll call you » (« Ne nous appelez pas, on vous appellera »), résume l’essence de l’inversion de contrôle (IoC) : le contrôle du flux ne vous appartient plus, il est délégué au framework.

Une fois le style et les patrons d’architecture choisis, la phase de développement commence par le choix d’un framework, qui apporte :

• Productivité : il évite de réécrire des mécanismes récurrents déjà résolus (routage des requêtes, accès aux données…).
• Standardisation : il impose des conventions communes à toute l’équipe, ce qui facilite la lecture et la maintenance du code par d’autres développeurs.
• Écosystème mature : documentation abondante, communauté active, plugins et intégrations déjà disponibles.
• Fiabilité : des modules critiques (authentification, protection CSRF, gestion des transactions) sont déjà éprouvés en production, plutôt que réimplémentés à la main avec les risques que cela comporte.
• Time-to-market : un socle solide permet de se concentrer sur la logique métier plutôt que sur la plomberie technique.

Pour Java, l’étude comparative porte sur Jakarta EE, Quarkus et Spring.

7. Spring et le marché de l’emploi

Les offres d’emploi pour un profil Développeur Java requièrent généralement :

• Maîtrise de Java et du framework Spring (Spring Boot, Spring Core, Spring Data, Spring Security…).
• La connaissance des microservices est un atout.
• Connaissance de Git et des outils de build (Maven, Gradle).
• Maîtrise des APIs REST.
• Connaissance d’Angular ou React.
• Connaissance de JPA / Hibernate.

Jakarta EE

Jakarta EE (anciennement Java EE) est un ensemble de spécifications standardisées pour construire des applications Java d’entreprise, implémentées par plusieurs serveurs d’application (WildFly, Payara, GlassFish…).

• Anciennement Java EE / J2EE, transféré à la fondation Eclipse en 2017.
• Approche par spécifications, avec plusieurs implémentations possibles.
• Composants historiques : EJB, JPA, CDI, JAX-RS, Servlet.
• Modèle traditionnel de serveur d’application, souvent plus lourd à déployer.

Micronaut

Micronaut est un framework moderne basé sur la JVM, qui permet de produire des microservices performants (il supporte Java, Groovy et Kotlin).

Il se rapproche fortement de Spring Boot et Quarkus et propose des fonctionnalités similaires : injection de dépendances, programmation orientée aspect et auto-configuration.

Quarkus

Quarkus est un framework Java cloud-native créé par Red Hat, conçu pour les conteneurs, le serverless et les microservices, avec un démarrage quasi instantané et une empreinte mémoire minimale.

• Créé en 2019 par Red Hat.
• Compilation native via GraalVM.
• Démarrage en millisecondes, faible consommation mémoire.
• Pensé pour Kubernetes, microservices et architectures serverless.

Concurrents de Spring

• Jakarta a perdu du terrain sur ses concurrents depuis l’arrêt de ses mises à jour pendant quelques années.
• Spring, Micronaut et Quarkus sont en concurrence sur le temps de lancement et l’occupation de la mémoire.
• L’évolutivité et l’architecture sans serveur sont aussi prises en considération dans les dernières versions de ces frameworks.

Qu’est-ce que Spring ?

Spring fournit une infrastructure complète pour développer des applications Java d’entreprise robustes, en s’appuyant sur des principes d’architecture éprouvés : couches, inversion de contrôle, programmation orientée aspect.

• Créé en 2003 par Rod Johnson.
• Alternative légère à J2EE / EJB.
• Écosystème très riche (Spring Boot, Cloud, Security…).

Principaux modules de l’écosystème (liste complète sur https://spring.io/projects) :

Critères de choix d’un framework

Le choix d’un framework backend ne se fait pas au hasard : plusieurs critères objectifs doivent guider la décision.

8. Architecture logique et architecture physique

Ce sont deux niveaux de description complémentaires d’une architecture logicielle : l’architecture logique définit ce que fait le code et comment il est organisé, l’architecture physique définit où tourne ce code et sur quelle infrastructure.

Architecture logique

Dans une application Spring Boot, la requête du client traverse trois couches et la réponse fait le chemin inverse :

Architecture physique N-Tiers

L’architecture N-Tiers organise une application en tiers distincts, chacun ayant une responsabilité précise et ne communiquant qu’avec le tier adjacent, ce qui favorise la séparation des préoccupations et facilite la maintenabilité du code.

Exemple avec N=4 :

Avantages :

• Séparation claire des responsabilités entre les tiers.
• Facilite la maintenance : une modification dans un tier n’impacte pas les autres.
• Chaque tier peut évoluer ou être remplacé indépendamment.
• Travail en équipe facilité : les développeurs frontend et backend travaillent sur des tiers distincts.
• Testabilité améliorée : chaque tier peut être testé de manière isolée.

Inconvénients :

• L’ensemble du backend reste déployé en un seul bloc.
• Une montée en charge nécessite de scaler toute l’application et non un tier spécifique.
• La multiplication des tiers peut introduire une latence supplémentaire.

9. À retenir

De l’entreprise au framework, chaque étape répond à une question :

• L’architecture répond à un besoin métier avant d’être un choix technique.
• Un style organise le système à grande échelle ; un patron résout un problème récurrent à l’intérieur d’un style.
• Le choix d’un style dépend toujours du contexte : sécurité, rapidité, charge, taille d’équipe.
• Spring n’est qu’un outil : il prend tout son sens une fois les concepts d’architecture compris.

Un style architectural répond à 5 questions fondamentales :