Aller au contenu

Mini-projet Spring Boot – La Chocolaterie de Pâques – Version 3

Évolution du projet

Après une première version centrée sur la gestion métier de la chocolaterie et une deuxième étape orientée application web CRUD avec Spring Boot, Thymeleaf, JPA et PostgreSQL, une version 3 du projet est désormais envisagée.

Cette nouvelle étape a pour objectif d’ajouter une vraie dimension applicative, sécurisée et professionnelle au projet.

L’application devra donc évoluer pour intégrer :

La charte graphique existante de la Chocolaterie de Pâques doit être conservée.
Les nouvelles pages doivent donc rester cohérentes avec le style CSS déjà fourni dans les templates.

1. Nouveau contexte

La Maison du Cacao Royal souhaite désormais ouvrir son application à 2 types d’utilisateurs :

1.1 L’administrateur du site

L’administrateur gère le contenu et le fonctionnement global de la boutique :

1.2 L’internaute client

Un internaute doit pouvoir :

L’application ne doit donc plus être pensée uniquement comme un outil de gestion interne, mais comme une application web complète avec sécurité et profils utilisateurs.

2. Objectifs de la version 3

Cette nouvelle étape du projet doit permettre de mettre en pratique :

3. Évolutions fonctionnelles attendues

3.1 Gestion des comptes utilisateurs

L’application doit intégrer une vraie gestion des utilisateurs.

Un utilisateur doit posséder au minimum :

Les rôles à prévoir au minimum :

3.2 Fonctionnalités côté administrateur

Un administrateur authentifié doit pouvoir accéder à une zone d’administration permettant :

L’administrateur doit également pouvoir :

3.3 Fonctionnalités côté client

Un internaute client doit pouvoir :

Contraintes importantes :

4. Sécurité attendue

4.1 Authentification

L’authentification doit être mise en place avec Spring Security. L’utilisateur doit pouvoir se connecter à l’aide de son email et de son mot de passe.

Le mot de passe doit être stocké de manière sécurisée, par exemple via un encodeur de mot de passe.

4.2 Autorisation

La sécurité doit s’appuyer sur les rôles.

Exemples de règles attendues :

4.3 Gestion de session

L’application doit proposer :

5. Nouvelles entités et adaptations du modèle

Le modèle existant doit évoluer.

5.1 Entités à conserver

Les entités métier existantes restent présentes :

5.2 Entités à ajouter

Vous devez ajouter au minimum :

Deux approches sont possibles :

Approche simple

Un champ role dans Utilisateur.

Approche plus évolutive

Une entité Role liée à Utilisateur.

Pour ce mini-projet, les 2 approches sont acceptables, à condition que le modèle reste propre.

6. Lien entre client métier et utilisateur de sécurité

Vous devez réfléchir à l’articulation entre :

Plusieurs choix sont possibles :

Option A – séparation stricte

Option B – fusion partielle

Pour ce projet, il est recommandé de privilégier une structure claire et maintenable.

7. Architecture attendue

Le projet doit continuer à respecter une architecture en couches :

fr/chocolaterie/
├── controller/
├── entity/
├── repository/
├── service/
├── security/
├── dto/
├── mapper/
├── config/
└── exception/

Éléments supplémentaires attendus :

8. Composants techniques attendus

8.1 Couche Entity

Elle doit contenir :

8.2 Couche Repository

Elle doit contenir les repositories JPA nécessaires pour :

8.3 Couche Service

Elle doit contenir :

8.4 Couche Controller

Elle doit contenir :

9. Gestion des vues Thymeleaf

Les templates fournis précédemment restent la base visuelle du projet.

Contraintes sur l’IHM :

Pages à ajouter au minimum :

Le style CSS existant doit être réutilisé et prolongé, pas remplacé brutalement.

10. Swagger / OpenAPI

Une documentation interactive de l’API doit être intégrée.

Objectifs :

Exemples de routes qui peuvent être documentées :

11. Vavr et Either

Dans cette version 3, vous pouvez introduire Vavr pour rendre la logique métier plus expressive.

11.1 Pourquoi utiliser Vavr ?

L’objectif est d’éviter une prolifération d’exceptions pour des cas métier prévisibles.

Exemples de cas métier adaptés à Either :

11.2 Exemple d’idée

Plutôt que de lever systématiquement une exception, vous pouvez retourner un résultat du type :

Intérêt :

12. Règles métier supplémentaires

En plus de la logique déjà attendue dans les versions précédentes, la version 3 doit intégrer les règles suivantes :

La logique de stock des versions précédentes reste applicable.

13. Sécurité des routes web et REST

Vous devez proposer une configuration de sécurité cohérente.

Exemples de routes publiques :

Exemples de routes réservées aux clients connectés :

Exemples de routes réservées à l’administrateur.trice :

Pour les routes REST :

14. Travail demandé

Partie 1 – Analyse

À partir du projet précédent :

  1. identifier les points à faire évoluer dans le modèle
  2. identifier les nouvelles entités nécessaires
  3. proposer une stratégie de gestion des utilisateurs et des rôles
  4. identifier les routes à sécuriser
  5. identifier les traitements métier pouvant être modélisés avec Either.

Partie 2 – Modèle et persistance

  1. créer les nouvelles entités
  2. mettre à jour les repositories
  3. adapter le script SQL PostgreSQL si nécessaire
  4. prévoir les données initiales utiles à la sécurité :
    • au moins un administrateur
    • au moins un client.

Partie 3 – Sécurité

  1. configurer Spring Security
  2. créer le mécanisme de connexion
  3. créer la page d’inscription
  4. sécuriser les routes
  5. gérer les rôles.

Partie 4 – Couche service

  1. créer les services liés à l’authentification et à l’inscription
  2. déplacer la logique métier sensible dans les services
  3. utiliser Either sur certains cas métier prévisibles.

Partie 5 – Contrôleurs et vues

  1. ajouter les contrôleurs nécessaires
  2. connecter les nouvelles pages Thymeleaf
  3. respecter la charte graphique existante
  4. gérer les redirections après authentification.

Partie 6 – Documentation API

  1. intégrer Swagger / OpenAPI
  2. documenter les endpoints
  3. vérifier l’accessibilité de la documentation.

15. Livrables attendus

Vous devez rendre :

16. Critères

17. Résultat attendu

À la fin de cette version 3, l’application doit permettre :

Côté administrateur

Côté client

Côté technique

18. Conseil de méthodologie

Travaillez dans cet ordre :

  1. modèle utilisateur / rôle
  2. sécurité
  3. inscription et connexion
  4. protection des routes
  5. adaptation de la logique métier
  6. intégration Swagger
  7. amélioration avec Vavr / Either.

N’essayez pas de tout faire d’un seul coup.

Commencez par tester :

Dans cette version 3, la chocolaterie passe du simple atelier de gestion à une vraie boutique en ligne.