╔══════════════════════════════════════════════════════════════════╗
║         PARCOURS ARCHITECTE JEE — VUE D'ENSEMBLE               ║
╚══════════════════════════════════════════════════════════════════╝

OBJECTIF
--------
Devenir un Architecte JEE capable de :
  - Concevoir des architectures robustes et scalables
  - Maîtriser les patterns d'entreprise
  - Guider les équipes de développement
  - Prendre des décisions techniques éclairées
  - Superviser la sécurité, la performance et le déploiement

DURÉE TOTALE ESTIMÉE : 12 à 18 mois (selon rythme)

═══════════════════════════════════════════════════════════════════
STRUCTURE DU PARCOURS (5 PHASES)
═══════════════════════════════════════════════════════════════════

  PHASE 1 — Fondations Architecturales                  (2-3 mois)
  PHASE 2 — Maîtrise JEE & Patterns Enterprise          (3-4 mois)
  PHASE 3 — Architecture Microservices                  (2-3 mois)
  PHASE 4 — Sécurité, Performance & Cloud               (2-3 mois)
  PHASE 5 — Leadership Technique & Gouvernance          (2-3 mois)

═══════════════════════════════════════════════════════════════════
LISTE DES FICHIERS DU PARCOURS
═══════════════════════════════════════════════════════════════════

  00_VUE_ENSEMBLE.txt         -> Ce fichier
  01_PHASE1_FONDATIONS.txt    -> Phase 1 : Fondations architecturales
  02_PHASE2_JEE_PATTERNS.txt  -> Phase 2 : JEE & Design Patterns
  03_PHASE3_MICROSERVICES.txt -> Phase 3 : Architecture Microservices
  04_PHASE4_SECURITE_CLOUD.txt-> Phase 4 : Sécurité, Perf & Cloud
  05_PHASE5_LEADERSHIP.txt    -> Phase 5 : Leadership & Gouvernance
  06_PROJETS_FILS_ROUGES.txt  -> Projets pratiques tout au long du parcours
  07_RESSOURCES_CERTIFICATIONS.txt -> Livres, certifications, communautés

═══════════════════════════════════════════════════════════════════
COMPÉTENCES FINALES D'UN ARCHITECTE JEE
═══════════════════════════════════════════════════════════════════

  TECHNIQUE
    - Maîtriser Jakarta EE (CDI, JPA, JAX-RS, EJB, JMS)
    - Concevoir des APIs REST professionnelles (OpenAPI, HATEOAS)
    - Sécuriser les applications (OAuth2, JWT, Keycloak)
    - Gérer la persistance (JPA avancé, caching, transactions)
    - Maîtriser les microservices (MicroProfile, Service Mesh)
    - Déployer en production (Docker, Kubernetes, CI/CD)

  ARCHITECTURE
    - Appliquer DDD (Domain-Driven Design)
    - Maîtriser les patterns (Repository, CQRS, Event Sourcing)
    - Concevoir des architectures hexagonales
    - Choisir entre Monolithe, SOA, Microservices

  LEADERSHIP
    - Documenter les décisions architecturales (ADR)
    - Guider les code reviews
    - Évaluer et choisir les technologies
    - Communiquer avec les parties prenantes non-techniques

═══════════════════════════════════════════════════════════════════
PRÉREQUIS AVANT DE COMMENCER
═══════════════════════════════════════════════════════════════════

  - Bases Java solides (POO, Collections, Exceptions)
  - Connaissance de Maven
  - Bases SQL et JDBC
  - Notions de HTTP et REST
  - Un IDE configuré (IntelliJ IDEA recommandé)
  - Docker installé
  - Git maîtrisé

═══════════════════════════════════════════════════════════════════
CONSEIL CLÉ
═══════════════════════════════════════════════════════════════════

  "Un architecte qui ne code pas devient rapidement obsolète.
   Codez chaque semaine. Pratiquez chaque concept."

                                  -> Commencer par 01_PHASE1_FONDATIONS.txt


╔══════════════════════════════════════════════════════════════════╗
║     PHASE 1 — FONDATIONS ARCHITECTURALES (2-3 mois)            ║
╚══════════════════════════════════════════════════════════════════╝

OBJECTIF DE LA PHASE
--------------------
Construire une base solide en Java avancé et comprendre les
concepts fondamentaux sur lesquels repose toute architecture
d'entreprise moderne.

═══════════════════════════════════════════════════════════════════
MODULE 1.1 — JAVA AVANCÉ POUR ARCHITECTES (3-4 semaines)
═══════════════════════════════════════════════════════════════════

POURQUOI CE MODULE ?
  Un architecte doit comprendre les mécanismes internes du langage
  pour prendre des décisions éclairées sur les performances,
  la maintenabilité et l'évolutivité du code.

--------------------------------------------------------------------
CHAPITRE 1 — POO AVANCÉE & PRINCIPES SOLID
--------------------------------------------------------------------

  CONCEPTS À MAÎTRISER :

  1. Les 5 principes SOLID
     S — Single Responsibility Principle (SRP)
         Chaque classe n'a qu'une seule raison de changer.
         Mauvais : UserService qui gère auth + email + BDD
         Bon    : UserService / AuthService / EmailService séparés

     O — Open/Closed Principle (OCP)
         Ouvert à l'extension, fermé à la modification.
         Utiliser les interfaces pour étendre sans modifier.

     L — Liskov Substitution Principle (LSP)
         Une sous-classe doit pouvoir remplacer sa super-classe.
         Eviter de surcharger des méthodes en les vidant.

     I — Interface Segregation Principle (ISP)
         Plusieurs petites interfaces valent mieux qu'une grande.
         Eviter les "god interfaces".

     D — Dependency Inversion Principle (DIP)
         Dépendre des abstractions, pas des implémentations.
         Fondement de l'injection de dépendances (CDI).

  2. Classes abstraites vs Interfaces (choix architectural)
     - Interface     : Contrat de comportement (ce qu'on fait)
     - Classe abstraite : Squelette d'implémentation (comment on le fait)
     - Règle          : Préférer les interfaces par défaut

  3. Records Java 16+ (immuabilité)
     public record User(String name, String email) {}
     Usage : DTOs, Value Objects (concepts DDD)

  4. Sealed Classes Java 17+ (hiérarchies fermées)
     Utile pour modéliser des états finis (State Pattern)

  EXERCICES :
    - Refactoriser une classe "god" en respectant SRP
    - Créer une hiérarchie de paiement (CB, Virement, Paypal)
      en appliquant OCP et LSP
    - Transformer des DTOs en Records

--------------------------------------------------------------------
CHAPITRE 2 — GENERICS, COLLECTIONS & STREAMS
--------------------------------------------------------------------

  CONCEPTS À MAÎTRISER :

  1. Generics avancés
     - Wildcard borné : <? extends T> (lecture) / <? super T> (écriture)
     - Type erasure : comprendre les implications runtime
     - Méthodes génériques : <T extends Comparable<T>> T max(List<T> list)

  2. Collections — choisir la bonne structure
     List    -> ArrayList (accès rapide), LinkedList (insertions fréquentes)
     Set     -> HashSet (unicité), TreeSet (ordre), LinkedHashSet (insertion order)
     Map     -> HashMap (performance), TreeMap (ordre), LinkedHashMap (LRU cache)
     Queue   -> ArrayDeque, PriorityQueue
     Concurrent -> ConcurrentHashMap, CopyOnWriteArrayList

  3. Streams API (Java 8+) — traitement fonctionnel
     - filter(), map(), flatMap(), reduce(), collect()
     - Collectors : groupingBy(), partitioningBy(), joining()
     - Streams parallèles : quand les utiliser (et quand ne pas)
     - Optional : éviter les NullPointerException

  4. Lambda & Functional Interfaces
     - Function<T,R>, Predicate<T>, Consumer<T>, Supplier<T>
     - Composition : andThen(), compose()
     - Method references : Class::method

  EXERCICES :
    - Implémenter un système de filtrage de produits avec Streams
    - Créer un cache LRU avec LinkedHashMap
    - Agréger des données de ventes par région avec Collectors

--------------------------------------------------------------------
CHAPITRE 3 — CONCURRENCE (ESSENTIEL EN ENTREPRISE)
--------------------------------------------------------------------

  CONCEPTS À MAÎTRISER :

  1. Thread Safety — les problèmes
     - Race conditions
     - Deadlocks (comment les éviter)
     - Memory visibility (happens-before)
     - volatile vs synchronized vs atomic

  2. ExecutorService — gestion des threads
     ExecutorService pool = Executors.newFixedThreadPool(10);
     Future<Result> future = pool.submit(() -> longTask());
     Result r = future.get(5, TimeUnit.SECONDS);

  3. CompletableFuture — programmation asynchrone
     CompletableFuture.supplyAsync(() -> fetchUser(id))
       .thenCompose(user -> fetchOrders(user))
       .thenApply(orders -> buildResponse(orders))
       .exceptionally(ex -> handleError(ex));

  4. Patterns de concurrence
     - Producer-Consumer avec BlockingQueue
     - Read-Write Lock pour données lues souvent, modifiées rarement
     - Semaphore pour limiter l'accès concurrent (rate limiting)

  EXERCICES :
    - Implémenter un système de traitement de commandes asynchrone
    - Créer un pool de connexions thread-safe
    - Simuler un problème de deadlock puis le résoudre

--------------------------------------------------------------------
CHAPITRE 4 — GESTION AVANCÉE DES EXCEPTIONS
--------------------------------------------------------------------

  CONVENTION ARCHITECTURALE :

  1. Hiérarchie d'exceptions métier
     ApplicationException (RuntimeException)
       └── BusinessException
             ├── ValidationException
             ├── ResourceNotFoundException
             ├── ConflictException
             └── AuthorizationException
       └── TechnicalException
             ├── DatabaseException
             └── IntegrationException

  2. Règles de l'architecte
     - Ne jamais avaler une exception silencieusement
     - Loguer au bon niveau (ERROR pour inattendu, WARN pour attendu)
     - Traduire les exceptions techniques en exceptions métier
     - Inclure des informations contextuelles (userId, requestId)

  3. Global Exception Handler (pattern JEE)
     @Provider
     public class GlobalExceptionMapper implements ExceptionMapper<Exception> {
         public Response toResponse(Exception ex) {
             // Mapper vers ErrorDTO
             // Retourner le bon code HTTP
         }
     }

═══════════════════════════════════════════════════════════════════
MODULE 1.2 — ARCHITECTURES D'ENTREPRISE (2-3 semaines)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 5 — STYLES D'ARCHITECTURE
--------------------------------------------------------------------

  1. ARCHITECTURE 3-TIERS (Classique)
     ┌─────────────────┐
     │  Présentation   │  <- Servlet / JSP / REST / Angular
     ├─────────────────┤
     │    Métier       │  <- Services / EJB / CDI Beans
     ├─────────────────┤
     │   Persistance   │  <- JPA / DAO / Repository
     └─────────────────┘
     Forces  : Simple, bien compris, facile à déployer
     Limites : Scalabilité difficile, tout couplé

  2. ARCHITECTURE HEXAGONALE (Ports & Adapters)
     Concept central : Le domaine métier est au centre.
     Il ne dépend d'aucune technologie externe.

     ┌─────────────────────────────────┐
     │         ADAPTATEURS             │
     │  (REST, JMS, Web, CLI, Tests)   │
     │         ┌─────────────┐         │
     │  PORTS  │   DOMAINE   │  PORTS  │
     │  (in)   │   MÉTIER    │  (out)  │
     │         └─────────────┘         │
     │  (JPA, Email, S3, Kafka)        │
     │         ADAPTATEURS             │
     └─────────────────────────────────┘

     Forces  : Testabilité, indépendance technologique
     Usage   : Applications complexes, durables dans le temps

  3. MONOLITHE vs SOA vs MICROSERVICES
     Critères de choix :

     MONOLITHE
       Quand : Petite équipe, démarrage, domaine simple
       Pro   : Simple à développer et déployer
       Con   : Scalabilité globale, déploiement monolithique

     SOA (Service Oriented Architecture)
       Quand : Grande entreprise avec systèmes legacy
       Pro   : Réutilisabilité des services
       Con   : ESB complexe, couplage encore fort

     MICROSERVICES
       Quand : Grande équipe, domaines distincts, scalabilité forte
       Pro   : Déploiement indépendant, scalabilité par service
       Con   : Complexité opérationnelle, réseau, données distribuées

  4. REST vs SOAP vs GraphQL vs gRPC
     REST    : Standard web, stateless, JSON — le plus utilisé
     SOAP    : XML, WS-Security — legacy, finance, B2B
     GraphQL : Requêtes flexibles — utile pour frontends riches
     gRPC    : HTTP/2, Protobuf — microservices internes, perf

--------------------------------------------------------------------
CHAPITRE 6 — DESIGN PATTERNS FONDAMENTAUX
--------------------------------------------------------------------

  PATTERNS CRÉATIONNELS
    Singleton     : Instance unique (à utiliser avec précaution)
    Factory       : Créer des objets sans spécifier la classe concrète
    Builder       : Construire des objets complexes étape par étape
    Prototype     : Cloner des objets existants

  PATTERNS STRUCTURELS
    Adapter       : Interface incompatible -> interface attendue
    Decorator     : Ajouter des comportements dynamiquement
    Facade        : Simplifier une interface complexe
    Proxy         : Contrôler l'accès à un objet (AOP, lazy loading)
    Composite     : Traiter des objets et des groupes uniformément

  PATTERNS COMPORTEMENTAUX
    Strategy      : Algorithmes interchangeables
    Observer      : Notification événements (CDI Events, JMS)
    Command       : Encapsuler une action (undo/redo)
    Template Method: Squelette d'algorithme, détails dans sous-classes
    State         : Comportement selon état (machines à états)
    Chain of Resp : Chaîne de handlers (filtres, middlewares)

  PATTERNS ENTERPRISE (Martin Fowler)
    Repository    : Abstraction couche d'accès aux données
    Unit of Work  : Gérer les transactions comme un ensemble
    Value Object  : Objets sans identité (Money, Address)
    Aggregate     : Groupe d'entités avec un root
    Service Layer : Façade pour la logique métier

═══════════════════════════════════════════════════════════════════
MODULE 1.3 — OUTILS DE L'ARCHITECTE (1 semaine)
═══════════════════════════════════════════════════════════════════

  MAVEN — Build & Gestion des dépendances
    - Structure multi-modules
    - Profiles (dev, test, prod)
    - Plugins essentiels (Surefire, Failsafe, Jacoco)
    - BOM (Bill of Materials) pour cohérence des versions

  GIT — Stratégie de branches
    - GitFlow : main, develop, feature/*, hotfix/*
    - Trunk-Based Development : branches éphémères
    - Conventional Commits : feat:, fix:, refactor:, docs:

  UML — Diagrammes architecturaux
    - Diagramme de classes (modèle domaine)
    - Diagramme de séquence (flux applicatif)
    - Diagramme de composants (architecture macro)
    - Diagramme de déploiement (infrastructure)

  ADR — Architecture Decision Records
    Format standard pour documenter les décisions :
    - Titre : "Utiliser JWT pour l'authentification"
    - Contexte : Pourquoi cette décision est nécessaire
    - Décision : Ce qui a été décidé
    - Conséquences : Positives et négatives

═══════════════════════════════════════════════════════════════════
PROJET FIL ROUGE PHASE 1 — "Bibliothèque Universitaire"
═══════════════════════════════════════════════════════════════════

  Objectif : Appliquer tous les concepts de la Phase 1

  Fonctionnalités :
    - Gestion des livres (CRUD)
    - Gestion des emprunteurs
    - Système d'emprunt avec règles métier
    - Notification de retard par email (async)

  Contraintes architecturales :
    - Architecture hexagonale
    - Principes SOLID respectés
    - Exceptions métier hiérarchisées
    - Tests unitaires (JUnit + Mockito)
    - Maven multi-modules

  Structure de projet :
    bibliotheque/
      ├── bibliotheque-domain/       <- Domaine pur (0 dépendance externe)
      ├── bibliotheque-application/  <- Cas d'usage / Services
      ├── bibliotheque-infrastructure/ <- JPA, Email, REST
      └── bibliotheque-webapp/       <- Point d'entrée (WildFly)

═══════════════════════════════════════════════════════════════════
CHECKLIST DE FIN DE PHASE 1
═══════════════════════════════════════════════════════════════════

  [ ] Je peux expliquer les 5 principes SOLID avec des exemples concrets
  [ ] Je sais choisir la bonne Collection selon le contexte
  [ ] Je maîtrise CompletableFuture pour le code asynchrone
  [ ] Je sais concevoir une hiérarchie d'exceptions métier
  [ ] Je peux dessiner une architecture hexagonale
  [ ] Je sais quand utiliser Monolithe vs Microservices
  [ ] J'ai appliqué au moins 5 Design Patterns
  [ ] J'ai structuré un projet Maven multi-modules
  [ ] J'ai rédigé mon premier ADR

════════════════════════════════════════════════════════════════
-> Suite : 02_PHASE2_JEE_PATTERNS.txt
════════════════════════════════════════════════════════════════


╔══════════════════════════════════════════════════════════════════╗
║   PHASE 2 — MAÎTRISE JEE & PATTERNS ENTERPRISE (3-4 mois)     ║
╚══════════════════════════════════════════════════════════════════╝

OBJECTIF DE LA PHASE
--------------------
Maîtriser l'écosystème Jakarta EE dans sa totalité et savoir
concevoir des applications d'entreprise robustes en appliquant
les patterns adaptés à chaque situation.

═══════════════════════════════════════════════════════════════════
MODULE 2.1 — CDI : L'ÂME DE JAKARTA EE (2 semaines)
═══════════════════════════════════════════════════════════════════

  CDI (Contexts and Dependency Injection) est le fondement
  de toute application Jakarta EE moderne.

--------------------------------------------------------------------
CHAPITRE 1 — CDI EN PROFONDEUR
--------------------------------------------------------------------

  1. INJECTION DE DÉPENDANCES
     @Inject vs @EJB — Différences et quand utiliser quoi
     @Inject       : CDI Bean standard (préféré en Jakarta EE 9+)
     @EJB          : Enterprise Java Bean (transactions, remote)

     Qualificateurs :
     @Qualifier permet de distinguer plusieurs implémentations :

     @Qualifier
     @Retention(RUNTIME)
     @Target({FIELD, METHOD, PARAMETER, TYPE})
     public @interface Premium {}

     @Premium
     public class PremiumPaymentService implements PaymentService {}

     @Inject @Premium
     private PaymentService paymentService; // -> injecte PremiumPaymentService

  2. SCOPES — Durée de vie des beans
     @RequestScoped      : Dure le temps d'une requête HTTP
     @SessionScoped      : Dure la session utilisateur
     @ApplicationScoped  : Singleton (partagé par toute l'app)
     @ConversationScoped : Contrôlé manuellement (multi-requêtes)
     @Dependent          : Scope du bean qui l'injecte (par défaut)

     RÈGLE ARCHITECTURALE :
       Préférer @ApplicationScoped pour les services sans état
       Préférer @RequestScoped pour les objets avec état par requête
       Éviter @SessionScoped autant que possible (scalabilité)

  3. INTERCEPTEURS CDI
     @InterceptorBinding
     @Retention(RUNTIME)
     @Target({METHOD, TYPE})
     public @interface Logged {}

     @Logged
     @Interceptor
     public class LoggingInterceptor {
         @AroundInvoke
         public Object log(InvocationContext ctx) throws Exception {
             long start = System.currentTimeMillis();
             Object result = ctx.proceed();
             long duration = System.currentTimeMillis() - start;
             logger.info("{} executed in {}ms", ctx.getMethod(), duration);
             return result;
         }
     }

     Usage des intercepteurs :
       - Logging transversal
       - Métriques de performance
       - Validation automatique
       - Gestion des transactions custom

  4. CDI EVENTS — Communication découplée
     // Producteur
     @Inject Event<OrderCreatedEvent> orderEvent;
     orderEvent.fire(new OrderCreatedEvent(orderId));

     // Observateur
     public void onOrderCreated(@Observes OrderCreatedEvent event) {
         // Envoyer email, mettre à jour stock...
     }

     // Asynchrone (Jakarta EE 10)
     public void onOrderAsync(@ObservesAsync OrderCreatedEvent event) {
         // Traitement en arrière-plan
     }

     AVANTAGE ARCHITECTURAL : Permet d'appliquer le pattern
     Observer sans couplage direct entre les composants.

  5. PRODUCERS & DISPOSERS
     @Produces
     @ApplicationScoped
     public EntityManager createEntityManager(EntityManagerFactory emf) {
         return emf.createEntityManager();
     }

     public void disposeEntityManager(@Disposes EntityManager em) {
         em.close();
     }

═══════════════════════════════════════════════════════════════════
MODULE 2.2 — JPA AVANCÉ (3-4 semaines)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 2 — JPA POUR ARCHITECTES
--------------------------------------------------------------------

  1. STRATÉGIES D'HÉRITAGE EN JPA
     a) SINGLE_TABLE   : Toutes sous-classes dans 1 table
        Pro : Performances, requêtes simples
        Con : Colonnes nullable, violation NF
        Usage : Hiérarchies peu profondes

     b) JOINED         : Une table par classe (+ jointures)
        Pro : Modèle normalisé
        Con : Jointures coûteuses
        Usage : Hiérarchies complexes avec données propres

     c) TABLE_PER_CLASS: Une table complète par classe concrète
        Pro : Pas de jointure
        Con : Requêtes polymorphiques lentes, duplication

  2. RELATIONS ET PERFORMANCES
     LAZY vs EAGER — Règle de l'architecte :
       @ManyToOne  -> EAGER par défaut -> Mettre LAZY si liste grande
       @OneToMany  -> LAZY par défaut -> Garder LAZY (toujours)
       @ManyToMany -> LAZY par défaut -> Garder LAZY (toujours)

     N+1 PROBLEM — Le piège classique :
       Problème : Pour N entités, N requêtes supplémentaires
       Solution : JOIN FETCH dans JPQL
         "SELECT u FROM User u JOIN FETCH u.orders"
       Ou : @EntityGraph
         @EntityGraph(attributePaths = {"orders", "orders.items"})
         List<User> findAllWithOrders();

  3. JPQL AVANCÉ & CRITERIA API
     // JPQL avec paramètres nommés
     TypedQuery<Order> query = em.createQuery(
         "SELECT o FROM Order o WHERE o.status = :status " +
         "AND o.total > :minAmount ORDER BY o.createdAt DESC",
         Order.class);
     query.setParameter("status", OrderStatus.PENDING);
     query.setParameter("minAmount", 100.0);
     query.setFirstResult(0).setMaxResults(20); // Pagination

     // Criteria API (type-safe)
     CriteriaBuilder cb = em.getCriteriaBuilder();
     CriteriaQuery<Order> cq = cb.createQuery(Order.class);
     Root<Order> order = cq.from(Order.class);
     cq.where(
         cb.equal(order.get("status"), OrderStatus.PENDING),
         cb.gt(order.get("total"), 100.0)
     );

  4. CACHING JPA
     Niveau 1 (L1) : Cache par EntityManager (automatique)
     Niveau 2 (L2) : Cache partagé entre EntityManagers
       @Entity
       @Cacheable
       @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
       public class Product {}

     Provider : Hibernate avec EhCache ou Infinispan
     Stratégies :
       READ_ONLY        : Données de référence (pays, catégories)
       READ_WRITE       : Données modifiées rarement
       NONSTRICT_READ_WRITE : Cohérence éventuelle acceptable
       TRANSACTIONAL    : Cohérence stricte requise

  5. TRANSACTIONS JPA — Concepts avancés
     PROPAGATION :
       REQUIRED        : Participe à la transaction existante (défaut)
       REQUIRES_NEW    : Nouvelle transaction systématiquement
       MANDATORY       : Doit avoir une transaction (sinon exception)
       NEVER           : Ne doit PAS avoir de transaction
       NOT_SUPPORTED   : Suspend la transaction existante

     ISOLATION LEVELS :
       READ_UNCOMMITTED : Dirty reads possibles
       READ_COMMITTED   : Pas de dirty reads (standard)
       REPEATABLE_READ  : Phantom reads possibles
       SERIALIZABLE     : Isolation totale (très lent)

     OPTIMISTIC vs PESSIMISTIC LOCKING :
       @Version          : Optimistic — vérifie à la mise à jour
       PESSIMISTIC_WRITE : Pessimistic — verrou en base de données

═══════════════════════════════════════════════════════════════════
MODULE 2.3 — JAX-RS : CONCEPTION D'APIs REST (3 semaines)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 3 — API REST PROFESSIONNELLE
--------------------------------------------------------------------

  1. CONVENTIONS DE NOMMAGE
     Ressource      URL                   Méthodes
     Collection   : /api/v1/orders        GET, POST
     Élément      : /api/v1/orders/{id}   GET, PUT, PATCH, DELETE
     Sous-resource: /api/v1/orders/{id}/items  GET, POST

     Codes HTTP corrects :
     200 OK          : Succès standard (GET, PUT)
     201 Created     : Ressource créée (POST) + Location header
     204 No Content  : Succès sans corps (DELETE, PUT sans retour)
     400 Bad Request : Données invalides
     401 Unauthorized: Non authentifié
     403 Forbidden   : Authentifié mais non autorisé
     404 Not Found   : Ressource inexistante
     409 Conflict    : Conflit (doublon, version)
     422 Unprocessable: Validation métier échouée
     500 Internal Server Error : Erreur technique

  2. STRUCTURE D'UNE API BIEN CONÇUE
     @Path("/api/v1/orders")
     @Produces(MediaType.APPLICATION_JSON)
     @Consumes(MediaType.APPLICATION_JSON)
     public class OrderResource {

         @GET
         public Response list(
             @QueryParam("page") @DefaultValue("0") int page,
             @QueryParam("size") @DefaultValue("20") int size,
             @QueryParam("status") OrderStatus status) {

             Page<OrderDTO> orders = orderService.findAll(page, size, status);
             return Response.ok(orders)
                 .header("X-Total-Count", orders.getTotalElements())
                 .build();
         }

         @POST
         public Response create(@Valid CreateOrderRequest request,
                                @Context UriInfo uriInfo) {
             OrderDTO created = orderService.create(request);
             URI location = uriInfo.getAbsolutePathBuilder()
                 .path(created.getId().toString()).build();
             return Response.created(location).entity(created).build();
         }
     }

  3. PAGINATION ET FILTRAGE
     Request  : GET /api/v1/products?page=2&size=10&sort=name,asc&category=books
     Response : {
                  "data": [...],
                  "page": 2,
                  "size": 10,
                  "totalElements": 156,
                  "totalPages": 16,
                  "_links": {
                    "self": "/api/v1/products?page=2&size=10",
                    "next": "/api/v1/products?page=3&size=10",
                    "prev": "/api/v1/products?page=1&size=10"
                  }
                }

  4. VALIDATION DES REQUÊTES
     @POST
     public Response create(@Valid @NotNull CreateOrderRequest request) {...}

     public class CreateOrderRequest {
         @NotBlank(message = "Le nom du client est obligatoire")
         @Size(max = 100)
         private String customerName;

         @NotNull
         @Positive
         private BigDecimal amount;

         @NotEmpty
         @Valid
         private List<OrderItemRequest> items;
     }

  5. VERSIONNING D'API
     Option 1 : URL Path (recommandé)       /api/v1/orders
     Option 2 : Header                      Accept: application/vnd.app.v2+json
     Option 3 : Query param                 /api/orders?version=2

     Stratégie de dépréciation :
     - Annoncer 3 mois avant
     - Header Deprecation: true dans les réponses
     - Documenter dans OpenAPI

  6. DOCUMENTATION OPENAPI
     @OpenAPIDefinition(
         info = @Info(title = "Order API", version = "1.0"),
         servers = @Server(url = "https://api.myapp.com")
     )
     @Operation(summary = "Créer une commande",
                description = "Crée une nouvelle commande pour un client")
     @APIResponse(responseCode = "201", description = "Commande créée")
     @APIResponse(responseCode = "400", description = "Données invalides")

═══════════════════════════════════════════════════════════════════
MODULE 2.4 — EJB & TRANSACTIONS ENTERPRISE (2 semaines)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 4 — EJB EN CONTEXTE MODERNE
--------------------------------------------------------------------

  NOTE ARCHITECTURALE :
  Avec Jakarta EE 10+, les EJB sont en partie remplacés par CDI.
  Mais ils restent essentiels pour : transactions CMT, remote calls,
  Timer Service, MDB.

  1. TYPES D'EJB ET USAGES
     @Stateless : Sans état, scalable, poolé — Services applicatifs
     @Stateful  : Garde état par client — Paniers, wizards
     @Singleton  : Instance unique — Configuration, cache
     @MessageDriven : Consommateur JMS

  2. TRANSACTIONS CONTAINER-MANAGED (CMT)
     @Stateless
     @TransactionManagement(CONTAINER)
     public class OrderService {

         @TransactionAttribute(TransactionAttributeType.REQUIRED)
         public Order createOrder(CreateOrderRequest req) {
             Order order = orderRepo.save(new Order(req));
             inventoryService.decreaseStock(req.getItems()); // même transaction
             notificationService.sendConfirmation(order);    // même transaction
             return order;
         }

         @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
         public void logAudit(AuditEvent event) {
             // Transaction séparée — commit même si l'appelant rollback
             auditRepo.save(event);
         }
     }

  3. TIMER SERVICE
     @Singleton
     public class ReportScheduler {

         @Schedule(hour = "2", minute = "0", persistent = false)
         public void generateDailyReport() {
             reportService.generate(LocalDate.now().minusDays(1));
         }

         @Schedule(second = "0", minute = "*/5", hour = "*", persistent = false)
         public void checkPendingOrders() {
             orderService.processPendingOrders();
         }
     }

═══════════════════════════════════════════════════════════════════
MODULE 2.5 — JMS : MESSAGING ENTERPRISE (2 semaines)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 5 — MESSAGING ASYNCHRONE
--------------------------------------------------------------------

  QUAND UTILISER JMS ?
  - Communication asynchrone entre services
  - Découpler des traitements longs (email, PDF, analytics)
  - Garantir la livraison de messages critiques
  - Équilibrer la charge (file de travaux)

  1. POINT-TO-POINT (Queue) — Un seul consommateur
     // Producteur
     @Inject JMSContext context;
     @Resource(lookup = "java:/jms/queue/orders")
     Queue ordersQueue;

     public void publishOrder(Order order) {
         context.createProducer()
             .setDeliveryMode(DeliveryMode.PERSISTENT) // Survivre aux redémarrages
             .setPriority(Message.DEFAULT_PRIORITY)
             .setTimeToLive(24 * 60 * 60 * 1000)       // 24h
             .send(ordersQueue, order);
     }

     // Consommateur (MDB)
     @MessageDriven(activationConfig = {
         @ActivationConfigProperty(propertyName = "destinationType",
                                   propertyValue = "javax.jms.Queue"),
         @ActivationConfigProperty(propertyName = "destinationLookup",
                                   propertyValue = "java:/jms/queue/orders")
     })
     public class OrderProcessor implements MessageListener {
         public void onMessage(Message message) {
             Order order = message.getBody(Order.class);
             processOrder(order);
         }
     }

  2. PUBLISH-SUBSCRIBE (Topic) — Plusieurs consommateurs
     Usage : Notifications, événements système, synchronisation de cache

  3. DEAD LETTER QUEUE (DLQ)
     Messages qui échouent sont redirigés vers une DLQ
     Monitorer la DLQ pour détecter les problèmes
     Rejouer les messages après correction

  4. GARANTIES DE LIVRAISON
     At-most-once  : Peut être perdu, jamais dupliqué
     At-least-once : Ne peut pas être perdu, peut être dupliqué
     Exactly-once  : Garantie totale (coût en performance)

═══════════════════════════════════════════════════════════════════
MODULE 2.6 — SÉCURITÉ JEE (2 semaines)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 6 — SÉCURITÉ EN PROFONDEUR
--------------------------------------------------------------------

  1. COUCHES DE SÉCURITÉ (Defense in Depth)
     L1 : Réseau (Firewall, WAF)
     L2 : Transport (HTTPS/TLS)
     L3 : Authentification (Qui êtes-vous ?)
     L4 : Autorisation (Qu'avez-vous le droit de faire ?)
     L5 : Validation des données (Injection prevention)
     L6 : Audit et logging (Qui a fait quoi et quand ?)

  2. JWT — JSON Web Token
     Structure : header.payload.signature
     Header    : {"alg": "RS256", "typ": "JWT"}
     Payload   : {"sub": "user123", "roles": ["ADMIN"], "exp": 1714000000}
     Signature : RSA ou HMAC de header + payload

     Bonnes pratiques :
     - Signer avec RS256 (asymétrique) en production
     - Expiration courte (15 min) + Refresh Token longue durée
     - Ne jamais stocker de données sensibles dans le payload
     - Révoquer via une blacklist Redis ou Refresh Token rotation

  3. FILTRE D'AUTHENTIFICATION JAX-RS
     @Provider
     @Priority(Priorities.AUTHENTICATION)
     public class JwtAuthFilter implements ContainerRequestFilter {

         public void filter(ContainerRequestContext context) {
             String authHeader = context.getHeaderString("Authorization");
             if (authHeader == null || !authHeader.startsWith("Bearer ")) {
                 context.abortWith(Response.status(401).build());
                 return;
             }
             try {
                 String token = authHeader.substring(7);
                 Claims claims = jwtService.verify(token);
                 context.setSecurityContext(new JwtSecurityContext(claims));
             } catch (JwtException e) {
                 context.abortWith(Response.status(401).build());
             }
         }
     }

  4. RBAC — CONTRÔLE D'ACCÈS PAR RÔLE
     @RolesAllowed({"ADMIN", "MANAGER"})
     public Response deleteOrder(@PathParam("id") Long id) { ... }

     @DenyAll
     public Response internalEndpoint() { ... }

     @PermitAll
     public Response publicEndpoint() { ... }

  5. TOP 10 OWASP — À connaître par cœur
     A01 : Broken Access Control      -> Toujours vérifier les droits
     A02 : Cryptographic Failures     -> TLS, hachage fort (bcrypt)
     A03 : Injection (SQL, LDAP...)   -> Requêtes paramétrées
     A04 : Insecure Design            -> Threat modeling
     A05 : Security Misconfiguration  -> Hardening serveur
     A06 : Vulnerable Components      -> Mise à jour des dépendances
     A07 : Auth & Session Failures    -> JWT, MFA
     A08 : Software Integrity         -> Vérifier les artefacts
     A09 : Security Logging Failures  -> Audit trail complet
     A10 : SSRF                       -> Valider les URLs externes

═══════════════════════════════════════════════════════════════════
PROJET FIL ROUGE PHASE 2 — "Plateforme E-Commerce"
═══════════════════════════════════════════════════════════════════

  Fonctionnalités à développer :
    - API REST complète (Catalogue, Commandes, Clients)
    - Authentification JWT
    - Gestion des stocks avec JMS (async)
    - Notifications email asynchrones
    - Cache JPA pour le catalogue
    - Transactions distribuées (Commande + Stock + Paiement)
    - Documentation OpenAPI auto-générée

  Technologies :
    - WildFly 30 / Jakarta EE 10
    - PostgreSQL + Hibernate
    - ActiveMQ pour JMS
    - Keycloak pour l'authentification

  Livrables attendus :
    - Code source avec tests (>80% couverture)
    - Diagramme de séquence des flux critiques
    - ADR pour les décisions majeures
    - Postman collection pour tester l'API

═══════════════════════════════════════════════════════════════════
CHECKLIST DE FIN DE PHASE 2
═══════════════════════════════════════════════════════════════════

  [ ] Je maîtrise CDI (scopes, qualificateurs, intercepteurs, events)
  [ ] Je gère JPA avancé (N+1, caching, héritage, optimistic locking)
  [ ] Je conçois des APIs REST conformes aux standards
  [ ] Je comprends les propagations de transactions
  [ ] Je sais utiliser JMS pour découpler les services
  [ ] Je sécurise une application avec JWT et RBAC
  [ ] Je connais le Top 10 OWASP et ses remèdes
  [ ] J'ai une application e-commerce fonctionnelle et sécurisée

════════════════════════════════════════════════════════════════
-> Suite : 03_PHASE3_MICROSERVICES.txt
════════════════════════════════════════════════════════════════


╔══════════════════════════════════════════════════════════════════╗
║     PHASE 3 — ARCHITECTURE MICROSERVICES (2-3 mois)           ║
╚══════════════════════════════════════════════════════════════════╝

OBJECTIF DE LA PHASE
--------------------
Comprendre, concevoir et déployer une architecture microservices
avec Jakarta EE / MicroProfile. Savoir prendre la décision
"microservices ou pas" de façon éclairée.

═══════════════════════════════════════════════════════════════════
MODULE 3.1 — FONDEMENTS DES MICROSERVICES (1 semaine)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 1 — EST-CE QUE LES MICROSERVICES SONT POUR MOI ?
--------------------------------------------------------------------

  LE PARADOXE DES MICROSERVICES
  "Les microservices résolvent des problèmes organisationnels,
   pas des problèmes techniques."

  COMMENCER PAR UN MONOLITHE MODULAIRE
  Avant de découper en microservices, structurer le monolithe :
    monolithe/
      ├── module-catalog/    <- Contexte Catalogue (bounded context)
      ├── module-orders/     <- Contexte Commandes
      ├── module-customers/  <- Contexte Clients
      └── module-shared/     <- Shared Kernel (minimum !)

  CRITÈRES POUR PASSER AUX MICROSERVICES
    [OK] Équipes > 8-10 personnes par service
    [OK] Besoins de scalabilité différents par domaine
    [OK] Cycles de déploiement indépendants nécessaires
    [OK] Technologies différentes justifiées
    [OK] Maturité DevOps de l'équipe
    [X] Ne pas migrer juste parce que c'est "moderne"

  COÛTS CACHÉS DES MICROSERVICES
    - Latence réseau entre services
    - Complexité des transactions distribuées
    - Debugging difficile (distributed tracing obligatoire)
    - Infrastructure plus complexe (Kubernetes, Service Mesh)
    - Tests d'intégration complexes

--------------------------------------------------------------------
CHAPITRE 2 — DECOMPOSITION EN SERVICES
--------------------------------------------------------------------

  DÉCOMPOSITION PAR DOMAINE MÉTIER (DDD)
  Bounded Context = Microservice (en général)

  Exemple : Système de livraison
    ┌──────────────────────────────────────────────────────┐
    │                    BOUNDED CONTEXTS                  │
    ├──────────────┬──────────────┬────────────────────────┤
    │   Commande   │   Livraison  │       Facturation      │
    │   Service    │   Service    │         Service        │
    ├──────────────┼──────────────┼────────────────────────┤
    │  - CreateOrder│ - AssignDriver│  - GenerateInvoice   │
    │  - CancelOrder│ - TrackLocation│ - ProcessPayment   │
    │  - GetOrder  │ - DeliverOrder │ - RefundPayment     │
    └──────────────┴──────────────┴────────────────────────┘

  ANTI-PATTERNS DE DÉCOMPOSITION
    [X] "Nano-services" : Trop petits, trop couplés
    [X] Services par couche technique (ex: "ServiceBase de données")
    [X] Services sans cohésion métier
    [X] Partage excessif de données entre services

  RÈGLE DE LA "PIZZA TEAM"
  Un service devrait être gérable par une équipe pouvant se
  nourrir avec 2 pizzas (5-8 personnes).

═══════════════════════════════════════════════════════════════════
MODULE 3.2 — MICROPROFILE (3 semaines)
═══════════════════════════════════════════════════════════════════

  MicroProfile est le standard Jakarta EE pour les microservices.
  Il s'appuie sur Jakarta EE et ajoute les fonctionnalités manquantes.

--------------------------------------------------------------------
CHAPITRE 3 — MICROPROFILE CONFIG
--------------------------------------------------------------------

  EXTERNALISER LA CONFIGURATION (12-Factor App)
  Ne jamais coder en dur : URLs, credentials, timeouts

  // Injection de configuration
  @Inject
  @ConfigProperty(name = "db.url")
  private String dbUrl;

  @Inject
  @ConfigProperty(name = "payment.timeout.ms", defaultValue = "5000")
  private int paymentTimeout;

  SOURCES DE CONFIGURATION (ordre de priorité)
  1. Variables d'environnement        (priorité haute)
  2. Propriétés système Java          (-Ddb.url=...)
  3. microprofile-config.properties   (src/main/resources)
  4. Valeurs par défaut (@ConfigProperty)

  CONFIGURATION PAR ENVIRONNEMENT
  dev.env  : db.url=jdbc:postgresql://localhost/myapp
  prod.env : db.url=jdbc:postgresql://prod-db:5432/myapp

--------------------------------------------------------------------
CHAPITRE 4 — MICROPROFILE FAULT TOLERANCE
--------------------------------------------------------------------

  RÉSILIENCE — Un service doit résister aux pannes des autres

  1. @Retry — Réessayer en cas d'échec
     @Retry(maxRetries = 3, delay = 500, jitter = 200,
            retryOn = {IOException.class, TimeoutException.class})
     public Payment processPayment(Order order) { ... }

  2. @Timeout — Ne pas attendre indéfiniment
     @Timeout(value = 5, unit = ChronoUnit.SECONDS)
     public Product getProduct(Long id) { ... }

  3. @CircuitBreaker — Couper si trop d'erreurs
     @CircuitBreaker(
         requestVolumeThreshold = 10,  // Fenêtre de 10 appels
         failureRatio = 0.5,            // 50% d'échecs -> ouverture
         delay = 30000                  // Attente 30s avant de réessayer
     )
     public Inventory checkInventory(Long productId) { ... }

     ÉTATS DU CIRCUIT BREAKER :
     CLOSED   -> Service normal, requêtes passent
     OPEN     -> Service défaillant, requêtes bloquées immédiatement
     HALF_OPEN -> Test de récupération (quelques requêtes passent)

  4. @Bulkhead — Limiter la concurrence
     @Bulkhead(value = 10,             // Max 10 appels parallèles
               waitingTaskQueue = 5)   // File d'attente de 5
     public Report generateReport(String type) { ... }

  5. @Fallback — Plan B en cas d'échec
     @Fallback(fallbackMethod = "getProductFromCache")
     @CircuitBreaker
     public Product getProduct(Long id) { ... }

     public Product getProductFromCache(Long id) {
         return cache.get(id).orElse(Product.UNAVAILABLE);
     }

  COMBINAISON RECOMMANDÉE PAR L'ARCHITECTE :
     @Retry -> @CircuitBreaker -> @Timeout -> @Fallback
  (L'ordre des annotations compte !)

--------------------------------------------------------------------
CHAPITRE 5 — MICROPROFILE HEALTH CHECKS
--------------------------------------------------------------------

  TYPES DE HEALTH CHECKS
  Liveness  : "Est-ce que l'application est vivante ?"
              Si non -> Kubernetes redémarre le pod
  Readiness : "Est-ce que l'application peut recevoir du trafic ?"
              Si non -> Kubernetes retire le pod du load balancer
  Startup   : "Est-ce que l'application a démarré ?"
              Évite les restarts prématurés au démarrage

  @ApplicationScoped
  @Liveness
  public class DatabaseHealthCheck implements HealthCheck {
      @Inject DataSource ds;

      public HealthCheckResponse call() {
          try (Connection c = ds.getConnection()) {
              return HealthCheckResponse.up("database");
          } catch (SQLException e) {
              return HealthCheckResponse.down("database");
          }
      }
  }

  ENDPOINTS GÉNÉRÉS :
  GET /health          -> Combinaison de tous
  GET /health/live     -> Liveness uniquement
  GET /health/ready    -> Readiness uniquement
  GET /health/started  -> Startup uniquement

--------------------------------------------------------------------
CHAPITRE 6 — MICROPROFILE METRICS & TRACING
--------------------------------------------------------------------

  METRICS — Métriques applicatives
  @Counted(name = "orders.created", description = "Nombre de commandes créées")
  @Timed(name = "orders.processing.time", description = "Temps de traitement")
  public Order createOrder(CreateOrderRequest req) { ... }

  Types de métriques :
  Counter    : Valeur qui ne fait que croître (nombre de requêtes)
  Gauge      : Valeur variable (taille du pool, mémoire)
  Timer      : Durée d'exécution
  Histogram  : Distribution de valeurs

  OPEN TELEMETRY — Distributed Tracing
  Permet de suivre une requête à travers plusieurs services

  @Traced
  public Order processOrder(Long orderId) {
      Order order = orderService.find(orderId); // Span 1
      inventory.reserve(order.getItems());       // Span 2
      payment.charge(order.getTotal());          // Span 3
      return order;
  }

  Visualisation : Jaeger, Zipkin

═══════════════════════════════════════════════════════════════════
MODULE 3.3 — COMMUNICATION ENTRE SERVICES (2 semaines)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 7 — SYNCHRONE vs ASYNCHRONE
--------------------------------------------------------------------

  COMMUNICATION SYNCHRONE (REST / gRPC)
  ┌──────────┐   HTTP    ┌──────────┐
  │ Service A│ ────────-> │ Service B│
  │          │ <-──────── │          │
  └──────────┘           └──────────┘
  Pro  : Simple, immédiat, résultat direct
  Con  : Couplage temporel, cascade d'erreurs

  MICROPROFILE REST CLIENT
  @RegisterRestClient(baseUri = "http://inventory-service")
  @Path("/api/v1/inventory")
  public interface InventoryClient {
      @GET
      @Path("/{productId}")
      Inventory getInventory(@PathParam("productId") Long id);

      @PUT
      @Path("/{productId}/reserve")
      void reserveItems(@PathParam("productId") Long id,
                        ReservationRequest request);
  }

  // Injection et utilisation
  @Inject
  @RestClient
  private InventoryClient inventoryClient;

  COMMUNICATION ASYNCHRONE (Events)
  ┌──────────┐            ┌──────────┐
  │ Service A│ ──event──-> │  Broker  │ ──event──-> │ Service B│
  └──────────┘            └──────────┘            └──────────┘
  Pro  : Découplage, résilience, scalabilité
  Con  : Complexité, cohérence éventuelle

  QUAND CHOISIR QUOI ?
  Synchrone   : Requête avec réponse immédiate requise
  Asynchrone  : Long traitement, notifications, fanout

--------------------------------------------------------------------
CHAPITRE 8 — APACHE KAFKA (Messaging Moderne)
--------------------------------------------------------------------

  Kafka est le standard pour les architectures event-driven.

  CONCEPTS CLÉS
  Topic     : Canal de messages (ex: "order-events")
  Partition : Parallélisme au sein d'un topic
  Offset    : Position d'un message dans une partition
  Consumer Group : Ensemble de consommateurs qui se partagent les partitions

  MICROPROFILE REACTIVE MESSAGING (Kafka)
  @ApplicationScoped
  public class OrderEventService {

      @Inject
      @Channel("order-events")
      Emitter<OrderEvent> emitter;

      public void publishOrderCreated(Order order) {
          emitter.send(new OrderCreatedEvent(order.getId(), order.getTotal()));
      }

      @Incoming("payment-events")
      public void onPaymentConfirmed(PaymentConfirmedEvent event) {
          orderService.confirmPayment(event.getOrderId());
      }
  }

  PATTERNS KAFKA AVANCÉS
  Outbox Pattern : Garantir que l'événement est publié avec la transaction
    1. Sauvegarder l'entité + l'événement dans la même transaction BDD
    2. Debezium lit le changelog BDD et publie dans Kafka
    3. Garantie exactly-once delivery

  Consumer Idempotency : Les consommateurs doivent gérer les doublons
    - Utiliser une clé d'idempotence (eventId)
    - Vérifier si déjà traité avant de traiter

--------------------------------------------------------------------
CHAPITRE 9 — API GATEWAY & SERVICE DISCOVERY
--------------------------------------------------------------------

  API GATEWAY — Point d'entrée unique
  ┌────────────────────────────────────────────┐
  │               API GATEWAY                 │
  │  - Routing         - Rate Limiting        │
  │  - Auth/JWT        - Load Balancing       │
  │  - SSL Termination - Request Aggregation  │
  └──────┬──────────┬──────────┬──────────────┘
         │          │          │
    ┌────┴──┐  ┌───┴───┐  ┌───┴──┐
    │Catalog│  │Orders │  │Users │
    └───────┘  └───────┘  └──────┘

  Solutions : Kong, NGINX, AWS API Gateway, Traefik

  SERVICE DISCOVERY — Comment les services se trouvent
  Client-Side : Client interroge le registre et choisit l'instance
    (Eureka + Ribbon)
  Server-Side : Load balancer interroge le registre et route
    (AWS ALB, Kubernetes Services)

  Avec Kubernetes : DNS interne suffit (service.namespace.svc.cluster.local)

═══════════════════════════════════════════════════════════════════
MODULE 3.4 — TRANSACTIONS DISTRIBUÉES (1 semaine)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 10 — LE PROBLÈME DES TRANSACTIONS DISTRIBUÉES
--------------------------------------------------------------------

  PROBLÈME : Sans transaction globale, les données peuvent être
  incohérentes entre services.

  Exemple : Créer une commande
  1. Sauvegarder la commande (Service Commandes) -> OK
  2. Déduire le stock (Service Inventaire)       -> ERREUR
  Résultat : Commande créée sans déduction de stock !

  SOLUTION 1 : SAGA PATTERN
  Séquence de transactions locales, compensées en cas d'erreur

  Saga Orchestrée (un orchestrateur central) :
  ┌────────────────────────────────────────────────────────────┐
  │                    SAGA ORCHESTRATEUR                     │
  └──┬───────────────────────────────────────────────────────┘
     │ 1. Create Order
     [BLACK_DOWN-POINTING_TRIANGLE]
  ┌──────────┐ 2. Reserve Inventory  ┌──────────┐
  │  Order   │ ────────────────────-> │Inventory │
  │ Service  │                       │ Service  │
  └──────────┘ <- ─ ─ ─ OK ─ ─ ─ ─   └──────────┘
     │ 3. Process Payment
     [BLACK_DOWN-POINTING_TRIANGLE]
  ┌──────────┐
  │ Payment  │  Si échec -> Compensate : Release Inventory + Cancel Order
  │ Service  │
  └──────────┘

  Saga Chorégraphiée (événements entre services) :
  Chaque service réagit aux événements des autres sans orchestrateur.

  SOLUTION 2 : EVENTUAL CONSISTENCY
  Accepter que les données soient temporairement incohérentes.
  Utiliser des événements et des réconciliations périodiques.

  RÈGLE ARCHITECTURALE :
  Avant d'implémenter des sagas, questionner le besoin réel.
  Souvent, redesigner les frontières de services évite le problème.

═══════════════════════════════════════════════════════════════════
PROJET FIL ROUGE PHASE 3 — "Système de Livraison"
═══════════════════════════════════════════════════════════════════

  Architecture à concevoir et implémenter :

  Services :
    order-service     : Gestion des commandes (Jakarta EE / WildFly)
    inventory-service : Gestion du stock (Quarkus + MicroProfile)
    delivery-service  : Attribution et suivi livraisons
    notification-service : Emails et SMS (consumer Kafka)

  Infrastructure :
    - API Gateway (Kong ou NGINX)
    - Apache Kafka (communication async)
    - PostgreSQL par service (DB isolée par service)
    - Prometheus + Grafana (métriques)
    - Jaeger (distributed tracing)

  Patterns à implémenter :
    - Circuit Breaker (inventory -> order)
    - Saga orchestrée (création de commande)
    - Outbox Pattern (publication d'événements fiables)
    - Health Checks sur tous les services
    - Rate Limiting sur l'API Gateway

═══════════════════════════════════════════════════════════════════
CHECKLIST DE FIN DE PHASE 3
═══════════════════════════════════════════════════════════════════

  [ ] Je sais quand utiliser les microservices (et quand ne pas)
  [ ] Je maîtrise MicroProfile (Config, Fault Tolerance, Health, Metrics)
  [ ] Je configure des Circuit Breakers
  [ ] J'utilise MicroProfile REST Client pour les appels inter-services
  [ ] Je comprends et j'utilise Kafka pour la communication async
  [ ] Je sais implémenter le pattern Saga
  [ ] J'ai configuré le distributed tracing (OpenTelemetry)
  [ ] Mon projet de livraison fonctionne avec tous les services

════════════════════════════════════════════════════════════════
-> Suite : 04_PHASE4_SECURITE_CLOUD.txt
════════════════════════════════════════════════════════════════


╔══════════════════════════════════════════════════════════════════╗
║   PHASE 4 — SÉCURITÉ AVANCÉE, PERFORMANCE & CLOUD (2-3 mois) ║
╚══════════════════════════════════════════════════════════════════╝

OBJECTIF DE LA PHASE
--------------------
Maîtriser la sécurité enterprise-grade, optimiser les performances
applicatives et déployer des applications Jakarta EE en production
sur une infrastructure cloud/conteneurisée.

═══════════════════════════════════════════════════════════════════
MODULE 4.1 — SÉCURITÉ ENTERPRISE (3 semaines)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 1 — OAUTH2 & OPENID CONNECT
--------------------------------------------------------------------

  OAUTH2 — Framework d'autorisation (pas d'authentification)
  Permet à un service d'accéder à des ressources au nom d'un utilisateur.

  FLUX OAUTH2 PRINCIPAUX

  1. Authorization Code Flow (Web Apps) — LE PLUS SÛUR
     ┌──────┐    1. Login Request    ┌─────────────┐
     │Client│ ─────────────────────-> │Authorization│
     │(Browser)│                     │Server (AS)  │
     │      │ <-───────────────────── │             │
     │      │  2. Auth Code          └─────────────┘
     │      │
     │      │  3. Exchange Code      ┌─────────────┐
     │Server│ ─────────────────────-> │     AS      │
     │(Backend)│                     │             │
     │      │ <-───────────────────── │             │
     │      │  4. Access Token       └─────────────┘
     │      │
     │      │  5. API Call + Token   ┌─────────────┐
     │      │ ─────────────────────-> │  Resource   │
     │      │ <-───────────────────── │  Server     │
     └──────┘  6. Protected Resource └─────────────┘

  2. Client Credentials Flow (Service-to-Service)
     Service A s'authentifie directement avec client_id + client_secret
     Usage : Microservices backend, jobs planifiés

  3. PKCE (Proof Key for Code Exchange)
     Extension obligatoire pour les apps mobiles et SPAs
     Protège contre l'interception du code d'autorisation

  OPENID CONNECT (OIDC) — Couche d'authentification sur OAuth2
  Ajoute : ID Token (JWT avec infos utilisateur), /userinfo endpoint
  Claims standard : sub, name, email, picture, locale

--------------------------------------------------------------------
CHAPITRE 2 — KEYCLOAK EN PROFONDEUR
--------------------------------------------------------------------

  Keycloak = Identity Provider (IdP) open-source basé sur OAuth2/OIDC

  CONCEPTS KEYCLOAK
  Realm    : Espace isolé (1 par application/organisation)
  Client   : Application qui utilise Keycloak (frontend, backend)
  User     : Utilisateur avec rôles et attributs
  Group    : Regroupement d'utilisateurs
  Role     : Permission ou ensemble de permissions
    - Realm Role  : Global au realm
    - Client Role : Spécifique à un client

  CONFIGURATION JAKARTA EE AVEC KEYCLOAK
  1. Configurer le client dans Keycloak :
     - Client ID : my-app-backend
     - Access Type : confidential
     - Valid Redirect URIs : https://myapp.com/*
     - Service Accounts : enabled (pour client credentials)

  2. Configuration WildFly / Quarkus :
     keycloak:
       auth-server-url: http://keycloak:8080
       realm: my-realm
       resource: my-app-backend
       credentials:
         secret: client-secret-from-keycloak
       bearer-only: true  # L'app vérifie les tokens, ne les crée pas

  3. Protection des endpoints :
     @ApplicationScoped
     @Path("/api/admin")
     @Authenticated
     public class AdminResource {

         @GET
         @RolesAllowed("admin")
         public Response getDashboard() { ... }

         @GET
         @Path("/users")
         @RolesAllowed({"admin", "manager"})
         public Response getUsers() { ... }
     }

  REFRESH TOKENS
  - Access Token  : Courte durée (5-15 minutes)
  - Refresh Token : Longue durée (8h-1 jour)
  - Rotation des Refresh Tokens : Chaque utilisation génère un nouveau

  PATTERNS AVANCÉS KEYCLOAK
  - Social Login : Google, GitHub, Microsoft
  - MFA (Multi-Factor Authentication)
  - Attribute-Based Access Control (ABAC)
  - User Federation (LDAP/Active Directory)
  - Custom Themes pour les pages de connexion

--------------------------------------------------------------------
CHAPITRE 3 — SÉCURITÉ DES MICROSERVICES
--------------------------------------------------------------------

  1. mTLS (Mutual TLS) — Service Mesh
     Chaque service présente un certificat
     Communication chiffrée et authentifiée entre services
     Géré par : Istio, Linkerd, Consul Connect

  2. ZERO TRUST ARCHITECTURE
     "Ne jamais faire confiance, toujours vérifier"
     - Pas de réseau de confiance implicite
     - Vérifier chaque requête même interne
     - Accès minimal (least privilege)
     - Journaliser tout

  3. SECRETS MANAGEMENT
     Ne jamais stocker les secrets dans le code ou les configs :
     - HashiCorp Vault (standard industrie)
     - Kubernetes Secrets (avec encryption at rest)
     - AWS Secrets Manager / Azure Key Vault

     @Inject
     @ConfigProperty(name = "quarkus.datasource.password")
     // Valeur vient de Vault via MicroProfile Config + vault-config-source

  4. API SECURITY CHECKLIST
     [ ] HTTPS partout (TLS 1.2 minimum, 1.3 recommandé)
     [ ] Validation de toutes les entrées
     [ ] Rate limiting sur tous les endpoints publics
     [ ] Headers de sécurité (CORS, CSP, HSTS, X-Frame-Options)
     [ ] Logs d'audit pour toutes les actions sensibles
     [ ] Rotation des clés JWT
     [ ] Scanning des dépendances (OWASP Dependency Check)
     [ ] Pénétration testing régulier

═══════════════════════════════════════════════════════════════════
MODULE 4.2 — PERFORMANCE & OPTIMISATION (3 semaines)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 4 — STRATÉGIES DE CACHE
--------------------------------------------------------------------

  NIVEAUX DE CACHE

  L1 — Application Cache (en mémoire)
    @ApplicationScoped
    public class ProductCache {
        private final Map<Long, Product> cache =
            new ConcurrentHashMap<>();

        public Product getOrLoad(Long id, Supplier<Product> loader) {
            return cache.computeIfAbsent(id, k -> loader.get());
        }
    }

  L2 — Distributed Cache (Redis / Infinispan)
    Partagé entre toutes les instances de l'application
    Survit aux redémarrages de l'application
    Cohérence entre les nœuds

    @Inject
    RemoteCache<String, Product> productCache;

    public Product getProduct(Long id) {
        String key = "product:" + id;
        Product cached = productCache.get(key);
        if (cached != null) return cached;

        Product product = productRepository.findById(id);
        productCache.put(key, product, 30, TimeUnit.MINUTES);
        return product;
    }

  L3 — HTTP Cache (CDN / Browser)
    Cache-Control: max-age=3600, public
    ETag: "abc123"
    Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

  STRATÉGIES D'INVALIDATION DU CACHE
  TTL (Time To Live)    : Expiration automatique après X secondes
  Cache Aside           : App gère le cache manuellement
  Write Through         : Écriture en cache + BDD simultanément
  Write Behind          : Écriture en cache, BDD asynchrone
  Read Through          : Cache gère le chargement depuis la BDD

--------------------------------------------------------------------
CHAPITRE 5 — OPTIMISATION JPA
--------------------------------------------------------------------

  1. IDENTIFIER LES N+1 QUERIES
     Activer le logging SQL Hibernate :
     hibernate.show_sql=true
     hibernate.format_sql=true
     hibernate.generate_statistics=true

     Outil : Hibernate Statistics, p6spy

  2. BATCH PROCESSING
     // Mauvais : INSERT 10000 requêtes individuelles
     for (Product p : products) { em.persist(p); }

     // Bon : Batch inserts
     @PersistenceContext(properties = {
         @PersistenceProperty(name = "hibernate.jdbc.batch_size", value = "50")
     })
     EntityManager em;

     for (int i = 0; i < products.size(); i++) {
         em.persist(products.get(i));
         if (i % 50 == 0) {
             em.flush();
             em.clear(); // Libérer la mémoire du L1 cache
         }
     }

  3. PROJECTIONS — Ne pas charger ce qu'on n'utilise pas
     // Mauvais : Charge toute l'entité avec ses relations
     List<User> users = em.createQuery("SELECT u FROM User u").getResultList();

     // Bon : DTO projection (ne charge que le nécessaire)
     public record UserSummary(Long id, String name, String email) {}

     List<UserSummary> users = em.createQuery(
         "SELECT new com.app.dto.UserSummary(u.id, u.name, u.email) FROM User u",
         UserSummary.class).getResultList();

  4. CONNECTION POOL TUNING
     WildFly / Quarkus (Agroal) :
     db.pool.min-size=5
     db.pool.max-size=20
     db.pool.acquisition-timeout=5000ms
     db.pool.leak-detection-interval=10s

     Règle générale : max_connections = (nb_cores * 2) + nb_disques

--------------------------------------------------------------------
CHAPITRE 6 — MONITORING & OBSERVABILITÉ
--------------------------------------------------------------------

  LES 3 PILIERS DE L'OBSERVABILITÉ
  Metrics  : Données numériques agrégées (nombre de requêtes, temps de réponse)
  Logs     : Événements textuels horodatés
  Traces   : Chemin d'une requête à travers les services

  STACK DE MONITORING RECOMMANDÉE
  ┌────────────────────────────────────────────────────────┐
  │                   GRAFANA (Visualisation)              │
  └──────────┬───────────────────────┬────────────────────┘
             │                       │
  ┌──────────[BLACK_DOWN-POINTING_TRIANGLE]──────────┐ ┌──────────[BLACK_DOWN-POINTING_TRIANGLE]──────────┐
  │    PROMETHEUS       │ │      JAEGER          │
  │    (Métriques)      │ │    (Tracing)         │
  └──────────┬──────────┘ └──────────┬──────────┘
             │                       │
  ┌──────────[BLACK_DOWN-POINTING_TRIANGLE]───────────────────────[BLACK_DOWN-POINTING_TRIANGLE]──────────┐
  │         APPLICATIONS (Instrumentées)         │
  │   MicroProfile Metrics / OpenTelemetry       │
  └──────────────────────────────────────────────┘

  LOGGING STRUCTURÉ (JSON)
  {
    "timestamp": "2024-01-15T10:30:00.000Z",
    "level": "INFO",
    "service": "order-service",
    "traceId": "abc123",
    "spanId": "def456",
    "userId": "user-789",
    "message": "Order created successfully",
    "orderId": "order-456",
    "duration_ms": 145
  }

  Outils : ELK Stack (Elasticsearch + Logstash + Kibana)
           ou Loki + Grafana (plus léger)

  SLI/SLO/SLA — Définir les objectifs
  SLI (Indicator) : Métrique mesurée (ex: taux d'erreur)
  SLO (Objective)  : Objectif sur le SLI (ex: < 1% d'erreurs)
  SLA (Agreement)  : Engagement contractuel basé sur les SLO
  Error Budget     : Tolérance aux indisponibilités

═══════════════════════════════════════════════════════════════════
MODULE 4.3 — DOCKER & KUBERNETES (3 semaines)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 7 — CONTAINERISATION JAKARTA EE
--------------------------------------------------------------------

  DOCKERFILE OPTIMISÉ POUR WILDFLY
  # Étape 1 : Build
  FROM maven:3.9-eclipse-temurin-21 AS builder
  WORKDIR /app
  COPY pom.xml .
  RUN mvn dependency:go-offline -B          # Cache des dépendances
  COPY src ./src
  RUN mvn package -DskipTests

  # Étape 2 : Image de prod (légère)
  FROM quay.io/wildfly/wildfly:30.0-jdk21
  COPY --from=builder /app/target/*.war $JBOSS_HOME/standalone/deployments/
  EXPOSE 8080 9990
  CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0"]

  MULTI-STAGE BUILD — Pourquoi ?
  Image finale sans Maven, sans sources, sans fichiers temp
  Résultat : Image ~300MB au lieu de ~800MB

  DOCKER COMPOSE POUR DÉVELOPPEMENT
  services:
    app:
      build: .
      ports: ["8080:8080"]
      environment:
        - DB_URL=jdbc:postgresql://db:5432/myapp
        - KAFKA_BROKERS=kafka:9092
      depends_on: [db, kafka]

    db:
      image: postgres:16
      environment:
        POSTGRES_DB: myapp
        POSTGRES_USER: appuser
        POSTGRES_PASSWORD: ${DB_PASSWORD}
      volumes: [pgdata:/var/lib/postgresql/data]

    kafka:
      image: confluentinc/cp-kafka:7.5.0
      environment:
        KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
        KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092

    keycloak:
      image: quay.io/keycloak/keycloak:23.0
      command: start-dev
      environment:
        KC_DB: postgres
        KC_DB_URL: jdbc:postgresql://db:5432/keycloak

--------------------------------------------------------------------
CHAPITRE 8 — KUBERNETES POUR ARCHITECTES
--------------------------------------------------------------------

  OBJETS KUBERNETES ESSENTIELS

  1. Deployment — Gérer les réplicas
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: order-service
  spec:
    replicas: 3
    strategy:
      type: RollingUpdate
      rollingUpdate:
        maxUnavailable: 1
        maxSurge: 1
    selector:
      matchLabels:
        app: order-service
    template:
      metadata:
        labels:
          app: order-service
      spec:
        containers:
        - name: order-service
          image: myregistry/order-service:1.2.3
          ports: [{containerPort: 8080}]
          resources:
            requests:
              memory: "256Mi"
              cpu: "250m"
            limits:
              memory: "512Mi"
              cpu: "500m"
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 8080
            initialDelaySeconds: 30
          livenessProbe:
            httpGet:
              path: /health/live
              port: 8080

  2. Service — Exposer les pods
  apiVersion: v1
  kind: Service
  metadata:
    name: order-service
  spec:
    selector:
      app: order-service
    ports:
    - port: 8080
      targetPort: 8080
    type: ClusterIP  # Interne seulement

  3. Ingress — Exposer vers l'extérieur
  apiVersion: networking.k8s.io/v1
  kind: Ingress
  spec:
    rules:
    - host: api.myapp.com
      http:
        paths:
        - path: /api/v1/orders
          pathType: Prefix
          backend:
            service:
              name: order-service
              port: {number: 8080}

  4. ConfigMap & Secret
  # ConfigMap : configuration non sensible
  kubectl create configmap app-config
    --from-literal=LOG_LEVEL=INFO
    --from-literal=CACHE_TTL=3600

  # Secret : données sensibles (base64 encodé)
  kubectl create secret generic app-secrets
    --from-literal=DB_PASSWORD=mysecretpassword

  HORIZONTAL POD AUTOSCALER (HPA)
  apiVersion: autoscaling/v2
  kind: HorizontalPodAutoscaler
  spec:
    scaleTargetRef:
      apiVersion: apps/v1
      kind: Deployment
      name: order-service
    minReplicas: 2
    maxReplicas: 20
    metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

═══════════════════════════════════════════════════════════════════
MODULE 4.4 — CI/CD PIPELINE (2 semaines)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 9 — PIPELINE DE DÉPLOIEMENT PROFESSIONNEL
--------------------------------------------------------------------

  GITHUB ACTIONS — Pipeline complet
  name: CI/CD Pipeline

  on:
    push:
      branches: [main, develop]
    pull_request:
      branches: [main]

  jobs:
    build-and-test:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4

        - name: Set up JDK 21
          uses: actions/setup-java@v4
          with:
            java-version: '21'
            distribution: 'temurin'

        - name: Cache Maven packages
          uses: actions/cache@v3
          with:
            path: ~/.m2
            key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}

        - name: Build and Unit Tests
          run: mvn clean package -Dskip.integration.tests=true

        - name: Integration Tests
          run: mvn verify -Pit  # Utilise Testcontainers

        - name: Code Quality (SonarQube)
          run: mvn sonar:sonar -Dsonar.token=${{ secrets.SONAR_TOKEN }}

        - name: OWASP Dependency Check
          run: mvn dependency-check:check

        - name: Build Docker Image
          run: |
            docker build -t myapp/order-service:${{ github.sha }} .
            docker push myapp/order-service:${{ github.sha }}

    deploy-staging:
      needs: build-and-test
      if: github.ref == 'refs/heads/develop'
      environment: staging
      steps:
        - name: Deploy to Kubernetes
          run: |
            kubectl set image deployment/order-service \
              order-service=myapp/order-service:${{ github.sha }} \
              --namespace=staging

    deploy-production:
      needs: build-and-test
      if: github.ref == 'refs/heads/main'
      environment: production
      steps:
        - name: Blue-Green Deployment
          run: ./scripts/blue-green-deploy.sh ${{ github.sha }}

  STRATÉGIES DE DÉPLOIEMENT
  Rolling Update    : Remplace progressivement les pods (défaut K8s)
  Blue-Green        : 2 environnements identiques, bascule instantanée
  Canary            : Déploiement progressif (5% -> 25% -> 100%)
  Feature Flags     : Déploiement sans activation (contrôle applicatif)

  QUALITY GATES (Portes de Qualité)
  Un déploiement ne peut passer que si :
  [ ] Couverture de tests > 80%
  [ ] Aucune vulnérabilité critique (OWASP)
  [ ] Code Smells SonarQube < 20 nouveaux
  [ ] Temps de build < 10 minutes
  [ ] Tous les tests d'intégration passent

═══════════════════════════════════════════════════════════════════
PROJET FIL ROUGE PHASE 4 — "Infrastructure Production-Ready"
═══════════════════════════════════════════════════════════════════

  Objectif : Rendre le système de livraison (Phase 3) production-ready

  Tâches :
    [ ] Intégrer Keycloak comme Identity Provider
    [ ] Configurer mTLS entre les microservices (Istio)
    [ ] Implémenter HashiCorp Vault pour les secrets
    [ ] Dockeriser tous les services
    [ ] Déployer sur Kubernetes (minikube ou k3s local)
    [ ] Configurer HPA sur les services critiques
    [ ] Mettre en place Prometheus + Grafana + Jaeger
    [ ] Créer le pipeline CI/CD complet (GitHub Actions)
    [ ] Implémenter le cache Redis sur le service catalogue
    [ ] Rédiger les runbooks opérationnels

═══════════════════════════════════════════════════════════════════
CHECKLIST DE FIN DE PHASE 4
═══════════════════════════════════════════════════════════════════

  [ ] Je maîtrise OAuth2 / OIDC et peux intégrer Keycloak
  [ ] Je gère les secrets de façon sécurisée (Vault ou équivalent)
  [ ] Je construis des images Docker optimisées (multi-stage)
  [ ] Je déploie sur Kubernetes avec HPA et health checks
  [ ] Mon pipeline CI/CD inclut tests, sécurité et qualité
  [ ] J'ai configuré le monitoring 3 piliers (metrics/logs/traces)
  [ ] Je comprends les stratégies de déploiement avancées
  [ ] Mon application est prête pour la production

════════════════════════════════════════════════════════════════
-> Suite : 05_PHASE5_LEADERSHIP.txt
════════════════════════════════════════════════════════════════


╔══════════════════════════════════════════════════════════════════╗
║      PHASE 5 — LEADERSHIP TECHNIQUE & GOUVERNANCE (2-3 mois)  ║
╚══════════════════════════════════════════════════════════════════╝

OBJECTIF DE LA PHASE
--------------------
Développer les compétences non-techniques d'un architecte :
communication, documentation, gouvernance, coaching des équipes
et prise de décision stratégique.

═══════════════════════════════════════════════════════════════════
MODULE 5.1 — DOMAIN-DRIVEN DESIGN (DDD) (3 semaines)
═══════════════════════════════════════════════════════════════════

  "Le DDD est avant tout une discipline de communication
   entre les experts métier et les développeurs."

--------------------------------------------------------------------
CHAPITRE 1 — DDD STRATÉGIQUE
--------------------------------------------------------------------

  1. UBIQUITOUS LANGUAGE — La langue commune
     Chaque concept a UN seul nom, partagé par tous.
     Les développeurs utilisent le vocabulaire métier dans le code.

     MAUVAIS EXEMPLE :
       Métier dit "commande", code dit "order", BDD dit "purchase"
     BON EXEMPLE :
       Tout le monde dit "commande" — code, BDD, discussions

     COMMENT CRÉER LE LANGAGE COMMUN ?
     - Ateliers Event Storming avec les experts métier
     - Glossaire maintenu et versionné
     - Code review refusé si les termes ne correspondent pas

  2. BOUNDED CONTEXTS — Les frontières
     Chaque contexte a son propre modèle et son propre langage.
     "Produit" dans le contexte Catalogue ≠ "Produit" dans Inventaire

     EXEMPLE : E-COMMERCE
     ┌──────────────────────────────────────────────────────────┐
     │  Contexte Catalogue      │   Contexte Commandes         │
     │  Product:                │   Product (simplifié):       │
     │   - name                 │    - productId               │
     │   - description          │    - price (at order time)   │
     │   - images               │    - quantity                │
     │   - categories           │                              │
     │   - seo_tags             │  Order:                      │
     │   - price_history        │    - items, total, status    │
     └──────────────────────────┴──────────────────────────────┘
     Remarque : "Product" est différent dans chaque contexte !

  3. CONTEXT MAP — Carte des relations entre contextes
     Relations possibles entre contextes :
     - Partnership          : Collaboration, dépendance mutuelle
     - Shared Kernel        : Modèle partagé (éviter si possible)
     - Customer-Supplier    : Un contexte dépend de l'autre
     - Conformist           : Dépendance totale au modèle externe
     - Anti-Corruption Layer: Traduction pour protéger son modèle
     - Open Host Service    : API publiée pour les autres
     - Separate Ways        : Pas de relation (duplication OK)

--------------------------------------------------------------------
CHAPITRE 2 — DDD TACTIQUE
--------------------------------------------------------------------

  1. ENTITÉS — Identité propre
     public class Order {
         private final OrderId id;          // Identité
         private CustomerId customerId;
         private List<OrderLine> lines = new ArrayList<>();
         private OrderStatus status;
         private Money total;

         // Logique métier dans le domaine !
         public void addLine(Product product, int quantity) {
             if (status != OrderStatus.DRAFT)
                 throw new IllegalStateException("Commande déjà validée");
             lines.add(new OrderLine(product.getId(), product.getPrice(), quantity));
             recalculateTotal();
         }

         public void confirm() {
             if (lines.isEmpty())
                 throw new BusinessException("Impossible de confirmer une commande vide");
             status = OrderStatus.CONFIRMED;
             // Publier un événement de domaine
             registerEvent(new OrderConfirmedEvent(this.id, this.total));
         }
     }

  2. VALUE OBJECTS — Pas d'identité, définis par leur valeur
     public record Money(BigDecimal amount, Currency currency) {
         public Money {
             Objects.requireNonNull(amount, "amount required");
             Objects.requireNonNull(currency, "currency required");
             if (amount.compareTo(BigDecimal.ZERO) < 0)
                 throw new IllegalArgumentException("Montant négatif interdit");
         }

         public Money add(Money other) {
             if (!this.currency.equals(other.currency))
                 throw new IllegalArgumentException("Devises différentes");
             return new Money(this.amount.add(other.amount), this.currency);
         }

         public static Money euros(BigDecimal amount) {
             return new Money(amount, Currency.getInstance("EUR"));
         }
     }

     // Autres exemples de Value Objects :
     // Email, Address, PhoneNumber, ProductId, CustomerId, OrderId

  3. AGGREGATES — Unité de cohérence
     Règles :
     - Un seul objet est la "racine" (Aggregate Root)
     - L'extérieur ne peut interagir qu'avec la racine
     - Une transaction ne modifie qu'un seul aggregate
     - Les aggregates communiquent via des événements de domaine

     Aggregate Root = Order
     ├── OrderLine (ne peut exister sans Order)
     └── ShippingAddress (Value Object)

  4. DOMAIN EVENTS — Ce qui s'est passé dans le domaine
     public record OrderConfirmedEvent(
         OrderId orderId,
         CustomerId customerId,
         Money total,
         Instant occurredAt) implements DomainEvent {}

     Usage : Découpler les effets secondaires (email, stock, analytics)

  5. REPOSITORIES — Abstraction de la persistance
     // Interface dans le domaine (pas de JPA ici !)
     public interface OrderRepository {
         Optional<Order> findById(OrderId id);
         List<Order> findByCustomer(CustomerId customerId, OrderStatus status);
         void save(Order order);
         void delete(OrderId id);
     }

     // Implémentation dans l'infrastructure
     @Repository
     public class JpaOrderRepository implements OrderRepository {
         @Inject EntityManager em;

         public Optional<Order> findById(OrderId id) {
             return Optional.ofNullable(em.find(OrderEntity.class, id.value()))
                 .map(OrderMapper::toDomain);
         }
     }

  6. SERVICES DOMAINE — Logique qui n'appartient pas à une entité
     // Logique de transfert d'argent : ne s'appartient ni à CompteSource
     // ni à CompteDestination -> Service de domaine
     public class TransfertService {
         public void transferer(Compte source, Compte destination, Money montant) {
             source.debiter(montant);
             destination.crediter(montant);
             // Publier TransfertEffectueEvent
         }
     }

  7. CQRS — COMMAND QUERY RESPONSIBILITY SEGREGATION
     Séparer les lectures des écritures

     COMMAND (écriture)          QUERY (lecture)
     CreateOrderCommand    ->     OrderSummaryQuery
     ConfirmOrderCommand   ->     OrderDetailsQuery
     CancelOrderCommand    ->     CustomerOrdersQuery

     Avantages :
     - Modèles optimisés séparément
     - Lecture peut utiliser des vues dénormalisées
     - Écriture peut être événementielle (Event Sourcing)

  8. EVENT SOURCING — Stocker les événements, pas l'état
     Au lieu de stocker l'état courant d'une commande,
     stocker tous les événements qui l'ont constitué :

     Table order_events :
     | order_id | seq | event_type        | payload              | timestamp |
     |----------|-----|-------------------|----------------------|-----------|
     | 123      | 1   | OrderCreated      | {customerId: 456...} | ...       |
     | 123      | 2   | ItemAdded         | {productId: 789...}  | ...       |
     | 123      | 3   | OrderConfirmed    | {total: 150.00}      | ...       |

     Reconstituer l'état : Rejouer tous les événements

═══════════════════════════════════════════════════════════════════
MODULE 5.2 — DOCUMENTATION ARCHITECTURALE (2 semaines)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 3 — DOCUMENTER COMME UN ARCHITECTE
--------------------------------------------------------------------

  1. ARCHITECTURE DECISION RECORDS (ADR)
     Format standard (Michael Nygard) :

     # ADR-001 : Utiliser JWT pour l'authentification

     ## Statut
     Accepté

     ## Contexte
     Notre application doit authentifier les utilisateurs.
     Nous avons des microservices qui doivent vérifier l'identité.
     L'équipe a 3 développeurs familiers avec JWT.

     ## Décision
     Nous utiliserons JWT (RS256) avec Keycloak comme Authorization Server.
     Les tokens auront une durée de vie de 15 minutes.
     Les Refresh Tokens dureront 8 heures.

     ## Conséquences
     Positives :
     - Stateless : pas de stockage de session serveur
     - Standard industrie : outillage mature
     - Compatible avec notre architecture microservices

     Négatives :
     - Révocation non instantanée (jusqu'à expiration)
     - Payload visible (ne pas mettre de données sensibles)
     - Keycloak = dépendance infrastructure supplémentaire

     ## Alternatives considérées
     - Sessions côté serveur (rejeté : scalabilité horizontale)
     - PASETO (rejeté : moins mature, moins de support)

  2. C4 MODEL — Visualiser l'architecture
     Niveau 1 : Context Diagram (Vue système)
       Montre l'application dans son environnement : utilisateurs, systèmes externes

     Niveau 2 : Container Diagram (Conteneurs applicatifs)
       Décompose en applications, APIs, bases de données

     Niveau 3 : Component Diagram (Composants)
       Décompose un conteneur en composants CDI, services, etc.

     Niveau 4 : Code Diagram (Classes)
       Seulement pour les parties complexes (optionnel)

  3. DIAGRAMMES DE SÉQUENCE — Flux critiques
     Documenter les flux critiques avec des diagrammes de séquence :
     - Authentification (OAuth2 flow)
     - Création de commande (avec saga)
     - Traitement d'un paiement

     Outil : PlantUML, Mermaid (dans le repo Git !)

  4. RUNBOOKS OPÉRATIONNELS
     Pour chaque composant critique :
     - Comment le démarrer / arrêter
     - Comment diagnostiquer les problèmes courants
     - Métriques à surveiller
     - Procédure de rollback

  5. README ARCHITECTURAL
     Chaque service doit avoir un README avec :
     - Responsabilité du service
     - API exposée (lien OpenAPI)
     - Dépendances (autres services, BDD, queues)
     - Comment lancer en local
     - Variables d'environnement
     - Contacts de l'équipe

═══════════════════════════════════════════════════════════════════
MODULE 5.3 — LEADERSHIP TECHNIQUE (2 semaines)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 4 — RÔLE DE L'ARCHITECTE AU QUOTIDIEN
--------------------------------------------------------------------

  1. CODE REVIEW — Guider sans bloquer
     Ce qu'un architecte cherche dans une PR :
     - Respect de l'architecture définie
     - Violations des principes SOLID
     - Problèmes de performance potentiels
     - Failles de sécurité
     - Absence de tests
     - Mauvaise gestion des erreurs

     Comment donner du feedback :
     [OK] "Je suggère de..." plutôt que "Tu dois..."
     [OK] Expliquer le pourquoi, pas juste le quoi
     [OK] Approuver ce qui est bien fait
     [OK] Distinguer : bloquant / recommandé / optionnel

  2. TECH RADAR — Cartographier les technologies
     Framework : ThoughtWorks Tech Radar
     4 quadrants : Languages, Platforms, Tools, Techniques
     4 zones     : Adopt, Trial, Assess, Hold

     Exemple :
     ADOPT  : Jakarta EE 10, Quarkus, Kubernetes, OpenTelemetry
     TRIAL  : GraalVM Native Image, Dapr
     ASSESS : WebAssembly (WASM), LLM integration
     HOLD   : Legacy EJB remote, SOAP (sauf legacy)

  3. ÉVALUATION DE TECHNOLOGIE
     Framework de décision pour adopter une nouvelle technologie :

     [ ] Maturité (versions stables, changelog actif)
     [ ] Communauté (stackoverflow, github issues)
     [ ] Licences (Apache, MIT -> OK / GPL -> attention)
     [ ] Sécurité (historique CVE, patch rapide)
     [ ] Performance (benchmarks indépendants)
     [ ] Learning curve (coût de formation équipe)
     [ ] Vendor lock-in (peut-on migrer ?)
     [ ] Support long terme (LTS)

  4. ARCHITECTURE REVIEW BOARD (ARB)
     Comité qui valide les décisions architecturales importantes.
     Composition : Architectes, tech leads, CTO/DSI
     Fréquence   : Hebdomadaire ou bi-hebdomadaire
     Processus   :
     1. Proposition avec ADR
     2. Revue par les pairs
     3. Vote / consensus
     4. Publication de la décision

  5. COMMUNIQUER AVEC LES NON-TECHNIQUES
     Traduire la technique en impact business :
     [X] "Nous avons un problème de N+1 queries dans JPA"
     [OK] "Les pages produits chargent 3x trop lentement,
         ce qui cause 25% d'abandon de panier"

     [X] "Nous devons migrer vers une architecture microservices"
     [OK] "Actuellement, une mise à jour du catalogue nécessite
         de redéployer l'intégralité de l'application,
         causant 10 minutes d'indisponibilité par semaine"

  6. ESTIMATION ARCHITECTURALE
     Méthode des T-Shirt sizes :
     XS : < 1 jour (bug, petit ajout)
     S  : 1-3 jours (feature simple)
     M  : 1-2 semaines (feature moyenne)
     L  : 1 mois (grand chantier)
     XL : 3+ mois (transformation)

     Toujours inclure dans l'estimation :
     - Temps de développement
     - Tests (unit + intégration)
     - Documentation
     - Code review
     - Déploiement et validation
     - Buffer d'imprévus (20-30%)

═══════════════════════════════════════════════════════════════════
MODULE 5.4 — ARCHITECTURE PATTERNS AVANCÉS (2 semaines)
═══════════════════════════════════════════════════════════════════

--------------------------------------------------------------------
CHAPITRE 5 — PATTERNS D'ARCHITECTURE ENTERPRISE
--------------------------------------------------------------------

  1. STRANGLER FIG PATTERN — Migration progressive
     Migrer un monolithe vers des microservices sans tout réécrire

     Étape 1 : API Gateway devant le monolithe
     Étape 2 : Extraire le premier service (le plus indépendant)
     Étape 3 : Router les requêtes vers le nouveau service
     Étape 4 : Éteindre la fonctionnalité dans le monolithe
     Répéter jusqu'à... migration complète ou arrêt si pas nécessaire

  2. BACKEND FOR FRONTEND (BFF)
     Un backend dédié par type de frontend :
     ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
     │ Mobile App  │    │   Web App   │    │  Third Party│
     └──────┬──────┘    └──────┬──────┘    └──────┬──────┘
            │                  │                  │
     ┌──────[BLACK_DOWN-POINTING_TRIANGLE]──────┐    ┌──────[BLACK_DOWN-POINTING_TRIANGLE]──────┐    ┌──────[BLACK_DOWN-POINTING_TRIANGLE]──────┐
     │  Mobile BFF │    │   Web BFF   │    │   API GW    │
     └──────┬──────┘    └──────┬──────┘    └──────┬──────┘
            │                  │                  │
            └──────────────────┴──────────────────┘
                               │
                    ┌──────────[BLACK_DOWN-POINTING_TRIANGLE]──────────┐
                    │   Backend Services  │
                    └─────────────────────┘

  3. SIDECAR PATTERN (Service Mesh)
     Chaque pod Kubernetes a un sidecar proxy (Envoy)
     Gère : mTLS, retry, circuit breaking, logging, tracing
     L'application ne connaît pas le réseau : le sidecar gère tout

  4. OUTBOX PATTERN — Garantie de publication d'événements
     Problème : Sauvegarder en BDD ET publier dans Kafka de façon atomique

     Solution :
     ┌─────────────────────────────────────────────────────┐
     │ @Transactional                                      │
     │ public void createOrder(CreateOrderRequest req) {  │
     │     Order order = orderRepo.save(new Order(req));  │
     │     // Dans la MÊME transaction :                  │
     │     outboxRepo.save(new OutboxEvent(               │
     │         "order-events",                            │
     │         new OrderCreatedEvent(order.getId())));    │
     │ }                                                   │
     └─────────────────────────────────────────────────────┘
               Debezium lit le changelog de la BDD
               et publie dans Kafka atomiquement

═══════════════════════════════════════════════════════════════════
PROJET FINAL — "Plateforme Bancaire Distribuée"
═══════════════════════════════════════════════════════════════════

  Le projet qui valide tout le parcours architecte.

  DESCRIPTION FONCTIONNELLE
  Système de gestion de comptes bancaires avec :
  - Gestion des clients et comptes
  - Virements nationaux et internationaux
  - Détection de fraude en temps réel
  - Reporting réglementaire
  - API pour partenaires externes

  EXIGENCES ARCHITECTURALES
  - DDD avec Bounded Contexts bien définis
  - Architecture hexagonale par service
  - Event Sourcing pour les transactions
  - CQRS pour les lectures (tableau de bord, historique)
  - Saga orchestrée pour les virements
  - Keycloak + OAuth2 + MFA
  - API Gateway avec rate limiting
  - Kafka pour tous les événements métier
  - Kubernetes avec autoscaling
  - Monitoring complet
  - CI/CD avec quality gates
  - Tests : unit, intégration, E2E, performance (Gatling)

  LIVRABLES ATTENDUS
  Documentation :
    [ ] Context Map DDD
    [ ] C4 Model complet (Level 1 à 3)
    [ ] ADR pour toutes les décisions majeures (min. 10 ADR)
    [ ] Diagrammes de séquence des flux critiques
    [ ] Runbooks opérationnels
    [ ] README architectural par service

  Code :
    [ ] Source complète sur GitHub
    [ ] >80% couverture de tests
    [ ] Tests de performance (Gatling)
    [ ] Pipeline CI/CD fonctionnel
    [ ] Docker Compose pour l'environnement local

  Présentation :
    [ ] Présentation de 30 minutes à un comité fictif
    [ ] Justification des choix architecturaux
    [ ] Analyse des compromis (trade-offs)

═══════════════════════════════════════════════════════════════════
CHECKLIST DE FIN DE PHASE 5 — VOUS ÊTES ARCHITECTE JEE
═══════════════════════════════════════════════════════════════════

  DDD
  [ ] Je maîtrise le langage ubiquitaire et les Bounded Contexts
  [ ] Je conçois des Aggregates corrects avec des Value Objects
  [ ] J'utilise les Domain Events pour découpler les contextes
  [ ] Je distingue CQRS et Event Sourcing et sais quand les utiliser

  DOCUMENTATION
  [ ] Je rédige des ADR clairs et complets
  [ ] Je crée des diagrammes C4 compréhensibles
  [ ] Je documente les flux critiques (séquences)
  [ ] Mes runbooks permettent à quelqu'un d'autre d'opérer le système

  LEADERSHIP
  [ ] Je conduis des code reviews constructives
  [ ] Je communique les enjeux techniques aux non-techniques
  [ ] Je maintiens un Tech Radar pour mon équipe
  [ ] J'estime les travaux de façon réaliste

  ARCHITECTURE
  [ ] Je sais appliquer le pattern Strangler Fig
  [ ] Je comprends et utilise le pattern Outbox
  [ ] Je conçois des systèmes résilients (circuit breaker, retry, fallback)
  [ ] Je prends des décisions architecturales justifiées et documentées

════════════════════════════════════════════════════════════════
-> Suite : 06_PROJETS_FILS_ROUGES.txt et 07_RESSOURCES_CERTIFICATIONS.txt
════════════════════════════════════════════════════════════════


╔══════════════════════════════════════════════════════════════════╗
║               PROJETS FIL ROUGE — TOUT LE PARCOURS             ║
╚══════════════════════════════════════════════════════════════════╝

  5 projets progressifs qui couvrent tout le parcours architecte.
  Chaque projet réutilise et enrichit les précédents.

═══════════════════════════════════════════════════════════════════
PROJET 1 — BIBLIOTHÈQUE UNIVERSITAIRE (Phase 1)
═══════════════════════════════════════════════════════════════════

  NIVEAU    : Débutant -> Intermédiaire
  DURÉE     : 3-4 semaines
  OBJECTIF  : Maîtriser l'architecture hexagonale et les fondations Java

  FONCTIONNALITÉS
  ├── Gestion des livres
  │     - Ajouter, modifier, supprimer, rechercher des livres
  │     - Catégories, auteurs, ISBN
  │     - Disponibilité en temps réel
  ├── Gestion des membres
  │     - Inscription, profil, historique
  │     - Limite d'emprunts par membre (règle métier)
  ├── Système d'emprunts
  │     - Emprunter un livre (vérifie les règles)
  │     - Retourner un livre
  │     - Prolonger un emprunt
  │     - Calculer les pénalités de retard
  └── Notifications asynchrones
        - Email de rappel avant date de retour
        - Email de confirmation d'emprunt

  ARCHITECTURE
  bibliotheque/
    ├── bibliotheque-domain/
    │     ├── src/main/java/com/bibliotheque/domain/
    │     │     ├── model/          <- Entités, Value Objects
    │     │     │     ├── Livre.java
    │     │     │     ├── Membre.java
    │     │     │     ├── Emprunt.java
    │     │     │     └── ISBN.java  (Value Object)
    │     │     ├── repository/     <- Interfaces des repositories
    │     │     ├── service/        <- Services de domaine
    │     │     └── exception/      <- Exceptions métier
    │     └── pom.xml
    ├── bibliotheque-application/
    │     └── src/main/java/com/bibliotheque/application/
    │           └── usecase/        <- Cas d'utilisation
    │                 ├── EmprunterLivreUseCase.java
    │                 └── RetournerLivreUseCase.java
    ├── bibliotheque-infrastructure/
    │     └── src/main/java/com/bibliotheque/infrastructure/
    │           ├── persistence/    <- JPA Entities, Repositories
    │           ├── notification/   <- Email (JavaMail)
    │           └── config/         <- CDI Producers
    └── bibliotheque-web/
          └── src/main/java/com/bibliotheque/web/
                └── rest/           <- JAX-RS Resources

  CONTRAINTES TECHNIQUES
  - Aucune dépendance JPA/CDI dans le module domain
  - 100% des cas d'utilisation testés (JUnit + Mockito)
  - Maven multi-modules (parent pom)
  - Principes SOLID respectés

  CRITÈRES DE VALIDATION
  [ ] Architecture hexagonale correctement implémentée
  [ ] Toutes les règles métier dans le domain
  [ ] Tests unitaires pour tous les use cases
  [ ] Gestion propre des exceptions
  [ ] Notifications asynchrones fonctionnelles

═══════════════════════════════════════════════════════════════════
PROJET 2 — PLATEFORME E-COMMERCE (Phase 2)
═══════════════════════════════════════════════════════════════════

  NIVEAU    : Intermédiaire
  DURÉE     : 4-6 semaines
  OBJECTIF  : API REST complète, sécurité JWT, JPA avancé, JMS

  FONCTIONNALITÉS
  ├── Catalogue produits
  │     - CRUD produits avec catégories et variantes
  │     - Recherche full-text, filtres, pagination
  │     - Cache JPA pour les produits
  │     - Import CSV en masse (JMS)
  ├── Gestion des clients
  │     - Inscription, authentification JWT
  │     - Profil, adresses multiples
  │     - Historique de commandes
  ├── Commandes
  │     - Panier (Stateful EJB)
  │     - Passer une commande
  │     - Gestion des statuts (DRAFT->CONFIRMED->SHIPPED->DELIVERED)
  │     - Annulation avec règles métier
  ├── Stock
  │     - Réservation asynchrone via JMS
  │     - Alertes stock bas
  └── Notifications
        - Email confirmation commande (JMS + Templates)
        - Email expédition avec numéro de suivi

  TECHNOLOGIES UTILISÉES
  - WildFly 30 + Jakarta EE 10
  - PostgreSQL + Hibernate 6
  - ActiveMQ pour JMS
  - Jackson pour JSON
  - OpenAPI/Swagger UI
  - Testcontainers pour les tests d'intégration

  API REST À IMPLÉMENTER
  GET  /api/v1/products              -> Liste paginée
  GET  /api/v1/products/{id}         -> Détail produit
  POST /api/v1/products              -> Créer (ADMIN)
  PUT  /api/v1/products/{id}         -> Modifier (ADMIN)
  POST /api/v1/auth/login            -> Authentification
  POST /api/v1/auth/refresh          -> Refresh Token
  GET  /api/v1/orders                -> Mes commandes
  POST /api/v1/orders                -> Créer commande
  GET  /api/v1/orders/{id}           -> Détail commande
  POST /api/v1/orders/{id}/cancel    -> Annuler

  CRITÈRES DE VALIDATION
  [ ] API conforme aux conventions REST
  [ ] JWT avec refresh token fonctionnel
  [ ] Tests d'intégration avec Testcontainers (>70% couverture)
  [ ] Documentation OpenAPI complète
  [ ] Cache JPA configuré et mesuré
  [ ] JMS pour les traitements asynchrones
  [ ] Postman collection fournie

═══════════════════════════════════════════════════════════════════
PROJET 3 — SYSTÈME DE LIVRAISON MICROSERVICES (Phase 3)
═══════════════════════════════════════════════════════════════════

  NIVEAU    : Avancé
  DURÉE     : 5-7 semaines
  OBJECTIF  : Architecture microservices avec Kafka, Fault Tolerance

  SERVICES À IMPLÉMENTER

  order-service (WildFly / Jakarta EE)
    Port : 8081
    BDD  : PostgreSQL order_db
    - Gestion des commandes
    - Publie : OrderCreated, OrderCancelled
    - Consomme : InventoryReserved, PaymentCompleted

  inventory-service (Quarkus + MicroProfile)
    Port : 8082
    BDD  : PostgreSQL inventory_db
    - Gestion du stock
    - Publie : InventoryReserved, InventoryReleased
    - Consomme : OrderCreated, OrderCancelled

  payment-service (WildFly / Jakarta EE)
    Port : 8083
    BDD  : PostgreSQL payment_db
    - Traitement des paiements (simulé)
    - Publie : PaymentCompleted, PaymentFailed
    - Consomme : InventoryReserved

  notification-service (Quarkus)
    Port : 8084
    BDD  : Aucune (stateless)
    - Envoie emails et SMS
    - Consomme : OrderCreated, PaymentCompleted, OrderShipped

  api-gateway (Kong ou NGINX)
    Port : 80/443
    - Routing
    - Rate Limiting
    - Auth validation

  INFRASTRUCTURE
  docker-compose.yml contenant :
  - kafka + zookeeper
  - postgresql (instances séparées par service)
  - keycloak
  - kong (API Gateway)
  - prometheus
  - grafana
  - jaeger

  SAGA ORCHESTRÉE À IMPLÉMENTER
  Flux de création de commande :
  1. order-service : Créer commande (status: PENDING)
  2. -> Publier OrderCreated
  3. inventory-service : Réserver le stock
  4. -> Publier InventoryReserved (ou InventoryFailed)
  5. payment-service : Traiter le paiement
  6. -> Publier PaymentCompleted (ou PaymentFailed)
  7. order-service : Confirmer la commande

  Compensation (rollback) si échec :
  PaymentFailed -> InventoryReleased -> OrderCancelled

  CRITÈRES DE VALIDATION
  [ ] Les 4 services communiquent via Kafka
  [ ] Circuit Breakers configurés (inventory -> order)
  [ ] Health checks actifs sur tous les services
  [ ] Distributed tracing visible dans Jaeger
  [ ] Métriques dans Grafana
  [ ] Saga orchestrée fonctionne (cas nominal et compensation)
  [ ] Docker Compose lève tout l'environnement

═══════════════════════════════════════════════════════════════════
PROJET 4 — INFRASTRUCTURE PRODUCTION-READY (Phase 4)
═══════════════════════════════════════════════════════════════════

  NIVEAU    : Expert
  DURÉE     : 4-5 semaines
  OBJECTIF  : Sécurité enterprise, Kubernetes, CI/CD complet

  AMÉLIORATION DU PROJET 3 :

  SÉCURITÉ
  [ ] Keycloak intégré avec OAuth2 + OIDC
  [ ] MFA activé pour les comptes admin
  [ ] mTLS entre microservices via Istio
  [ ] Secrets dans HashiCorp Vault
  [ ] Scan de vulnérabilités dans le pipeline

  KUBERNETES
  [ ] Manifestes YAML pour tous les services
  [ ] HPA configuré (scale: 2->20 pods)
  [ ] ResourceQuotas et LimitRanges
  [ ] NetworkPolicies (isolation réseau)
  [ ] PodDisruptionBudget (disponibilité maintenue)
  [ ] Rolling updates sans interruption

  CI/CD (GitHub Actions)
  Phase 1 : Build + Tests unitaires
  Phase 2 : Tests d'intégration (Testcontainers)
  Phase 3 : Quality Gates (SonarQube, OWASP)
  Phase 4 : Build Docker + Push Registry
  Phase 5 : Deploy Staging (auto sur develop)
  Phase 6 : Deploy Production (manuel + approval)
  Phase 7 : Smoke tests post-déploiement

  PERFORMANCE
  [ ] Tests de charge avec Gatling
       Objectifs : 1000 req/s avec P99 < 200ms
  [ ] Cache Redis pour le catalogue (hit rate > 80%)
  [ ] Connection pool configuré et mesuré
  [ ] Rapport de performance documenté

  CRITÈRES DE VALIDATION
  [ ] Pipeline CI/CD entièrement fonctionnel
  [ ] Déploiement Kubernetes avec 0 downtime
  [ ] Tous les secrets dans Vault
  [ ] Tests de charge réussis (1000 req/s P99<200ms)
  [ ] Dashboard Grafana avec alertes configurées

═══════════════════════════════════════════════════════════════════
PROJET 5 — PLATEFORME BANCAIRE DISTRIBUÉE (Phase 5)
═══════════════════════════════════════════════════════════════════

  NIVEAU    : Architecte Expert
  DURÉE     : 8-12 semaines
  OBJECTIF  : Synthèse complète du parcours + DDD + Leadership

  Voir description complète dans 05_PHASE5_LEADERSHIP.txt

  SERVICES À CONCEVOIR
  ├── account-service        <- Comptes clients (Event Sourcing)
  ├── transaction-service    <- Virements (Saga + CQRS)
  ├── fraud-service          <- Détection temps réel (Kafka Streams)
  ├── notification-service   <- Alertes clients
  ├── reporting-service      <- CQRS read side, analytics
  └── api-gateway            <- Point d'entrée unique

  BOUNDED CONTEXTS DDD
  ├── Gestion des comptes    <- account-service
  ├── Virements              <- transaction-service
  ├── Conformité/Fraude      <- fraud-service
  └── Reporting              <- reporting-service

  RÉSULTATS ATTENDUS
  Ce projet démontre la capacité à :
  - Décomposer un domaine complexe avec DDD
  - Concevoir une architecture Event Sourcing + CQRS
  - Sécuriser une application de niveau financier
  - Gérer les transactions distribuées (Saga)
  - Documenter et communiquer les décisions architecturales

════════════════════════════════════════════════════════════════
-> Suite : 07_RESSOURCES_CERTIFICATIONS.txt
════════════════════════════════════════════════════════════════


╔══════════════════════════════════════════════════════════════════╗
║              RESSOURCES & CERTIFICATIONS ARCHITECTE JEE        ║
╚══════════════════════════════════════════════════════════════════╝

═══════════════════════════════════════════════════════════════════
LIVRES ESSENTIELS PAR PHASE
═══════════════════════════════════════════════════════════════════

PHASE 1 — FONDATIONS
  "Effective Java" — Joshua Bloch
    -> La bible du développeur Java senior
    -> Incontournable pour comprendre les subtilités du langage

  "Clean Code" — Robert C. Martin (Uncle Bob)
    -> Rédiger un code lisible, maintenable
    -> Exemples en Java, applicable partout

  "Design Patterns" — Gang of Four (GoF)
    -> Les 23 patterns originaux
    -> Référence absolue sur les patterns créationnels/structurels/comportementaux

PHASE 2 — JEE & PATTERNS ENTERPRISE
  "Patterns of Enterprise Application Architecture" — Martin Fowler
    -> Repository, Unit of Work, Service Layer, Data Mapper
    -> Indispensable pour concevoir des applications d'entreprise

  "Jakarta EE Cookbook" — Rhuan Rocha
    -> Guide pratique Jakarta EE moderne
    -> Recettes pour CDI, JPA, JAX-RS, Security

  "RESTful Web Services" — Leonard Richardson
    -> Concevoir des APIs REST de qualité

PHASE 3 — MICROSERVICES
  "Building Microservices" — Sam Newman
    -> La référence absolue sur les microservices
    -> Patterns, décomposition, opérations

  "Designing Distributed Systems" — Brendan Burns (co-fondateur Kubernetes)
    -> Patterns distribués avec conteneurs

  "Kafka: The Definitive Guide" — Gwen Shapira & al.
    -> Kafka en profondeur pour architectes

PHASE 4 — SÉCURITÉ & CLOUD
  "OAuth 2 in Action" — Justin Richer & Antonio Sanso
    -> OAuth2 et OIDC expliqués de façon exhaustive

  "Kubernetes in Action" — Marko Luksa
    -> K8s pour développeurs et architectes
    -> Exemples très complets

  "Site Reliability Engineering" — Google (SRE Book, gratuit en ligne)
    -> SLI/SLO/SLA, error budgets, toil
    -> Comment opérer des systèmes à grande échelle

PHASE 5 — DDD & ARCHITECTURE
  "Domain-Driven Design" — Eric Evans (le livre bleu)
    -> La référence originale du DDD stratégique et tactique
    -> Dense, mais indispensable

  "Implementing Domain-Driven Design" — Vaughn Vernon (le livre rouge)
    -> Application pratique du DDD avec du code Java

  "Building Event-Driven Microservices" — Adam Bellemare
    -> Event Sourcing, CQRS, Kafka dans les microservices

  "Software Architecture: The Hard Parts" — Neal Ford & Mark Richards
    -> Compromis architecturaux, microservices en production

  "Clean Architecture" — Robert C. Martin
    -> Architecture hexagonale, dépendances, principes

═══════════════════════════════════════════════════════════════════
CERTIFICATIONS PAR ORDRE DE PRIORITÉ
═══════════════════════════════════════════════════════════════════

TIER 1 — PRIORITÉ HAUTE (Recommandées)

  Oracle Certified Professional : Java SE 21 Developer
    Niveau     : Professionnel
    Prérequis  : Bases Java solides
    Valeur     : Très reconnue par les employeurs
    Contenu    : POO, Generics, Streams, Concurrence, Modules
    Durée prep : 2-3 mois

  Oracle Certified Professional : Jakarta EE Application Developer
    Niveau     : Professionnel (ex-Java EE 8)
    Prérequis  : OCP Java SE
    Valeur     : Standard pour les postes JEE
    Contenu    : CDI, JPA, JAX-RS, EJB, JMS, Security
    Durée prep : 3-4 mois

TIER 2 — TRÈS UTILES

  Certified Kubernetes Application Developer (CKAD)
    Organisme  : Cloud Native Computing Foundation (CNCF)
    Niveau     : Intermédiaire
    Format     : Examen pratique (hands-on)
    Valeur     : Très demandée pour les postes cloud
    Durée prep : 2-3 mois

  AWS Solutions Architect — Associate
    Organisme  : Amazon Web Services
    Niveau     : Intermédiaire
    Valeur     : Excellent si déploiement sur AWS
    Contenu    : Architecture cloud, services AWS, bonnes pratiques

  Red Hat Certified Enterprise Application Developer (EX183)
    Organisme  : Red Hat
    Format     : Examen pratique sur WildFly/Quarkus
    Valeur     : Très appréciée dans les entreprises utilisant Red Hat

TIER 3 — SPÉCIALISATIONS

  Certified Kubernetes Administrator (CKA)
    Pour les architectes responsables de l'infrastructure K8s

  Google Professional Cloud Architect
    Pour les déploiements GCP

  AWS Certified Solutions Architect — Professional
    Niveau avancé après l'Associate

═══════════════════════════════════════════════════════════════════
RESSOURCES EN LIGNE
═══════════════════════════════════════════════════════════════════

DOCUMENTATION OFFICIELLE
  Jakarta EE       : https://jakarta.ee/specifications
  MicroProfile     : https://microprofile.io/specifications
  WildFly          : https://docs.wildfly.org
  Quarkus          : https://quarkus.io/guides
  Hibernate        : https://docs.jboss.org/hibernate/orm
  Keycloak         : https://www.keycloak.org/documentation
  Kafka            : https://kafka.apache.org/documentation

COURS EN LIGNE RECOMMANDÉS
  Udemy
    "Jakarta EE and MicroProfile" — Reza Rahman
    "Kubernetes for Java Developers" — Arun Gupta
    "Domain Driven Design & Microservices for Architects"

  Pluralsight
    "Java EE: Getting Started with CDI"
    "Microservices Architecture"
    "Kubernetes for Developers"

  YouTube (Gratuit)
    Devoxx (conférences Java de qualité)
    JUG (Java User Groups)
    Quarkus.io channel
    GOTO Conferences

BLOGS & SITES
  Baeldung          : https://www.baeldung.com (Java/Spring/JEE)
  Martin Fowler     : https://martinfowler.com (Architecture, DDD)
  InfoQ             : https://www.infoq.com (Architecture, Microservices)
  The Server Side   : https://www.theserverside.com
  Thoughts on Java  : https://thorben-janssen.com (JPA/Hibernate expert)

PODCASTS
  "Software Engineering Radio"     : Épisodes sur architecture, DDD
  "Arrested DevOps"                : DevOps, SRE
  "The InfoQ Podcast"              : Actualités architecture
  "Java Pub House"                 : Java moderne

COMMUNAUTÉS
  Jakarta EE Working Group         : https://jakarta.ee/connect
  MicroProfile Google Group        : https://groups.google.com/g/eclipse-microprofile
  Stack Overflow                   : Tags: jakarta-ee, jpa, cdi, jax-rs
  Reddit: r/java, r/microservices, r/kubernetes

═══════════════════════════════════════════════════════════════════
OUTILS DE L'ARCHITECTE
═══════════════════════════════════════════════════════════════════

DÉVELOPPEMENT
  IntelliJ IDEA Ultimate  : IDE recommandé (plugins JEE, K8s, Quarkus)
  VS Code                 : Pour éditer YAML, Dockerfiles, scripts
  DBeaver                 : Client BDD universel
  Postman / Insomnia      : Tests d'APIs REST
  JMeter / Gatling        : Tests de charge

ARCHITECTURE & DOCUMENTATION
  draw.io (diagrams.net) : Diagrammes C4, UML, Architecture
  PlantUML               : Diagrammes en code (dans Git !)
  Confluence             : Documentation d'équipe
  Miro / Mural           : Event Storming en ligne

MONITORING & OBSERVABILITÉ
  Prometheus + Grafana   : Métriques
  Jaeger / Zipkin        : Distributed Tracing
  ELK Stack (Elastic)    : Logs centralisés
  Loki + Grafana         : Logs (plus léger)
  Kiali                  : Visualisation Service Mesh Istio

SÉCURITÉ
  OWASP ZAP              : Scan de vulnérabilités
  Trivy                  : Scan d'images Docker
  HashiCorp Vault        : Gestion des secrets
  Keycloak               : Identity Provider

DÉPLOIEMENT
  Docker Desktop         : Développement local
  Minikube / k3s         : Kubernetes local
  Helm                   : Package manager Kubernetes
  ArgoCD                 : GitOps pour Kubernetes
  Terraform              : Infrastructure as Code

BUILD & CI
  Maven                  : Build Java standard
  GitHub Actions         : CI/CD (recommandé)
  SonarQube              : Qualité de code
  Nexus / Artifactory    : Registry d'artefacts

═══════════════════════════════════════════════════════════════════
FEUILLE DE ROUTE VERS L'EMPLOI D'ARCHITECTE
═══════════════════════════════════════════════════════════════════

ÉTAPES CONCRÈTES

  Mois 1-6  (Phases 1 et 2)
  -> Consolider Java, maîtriser Jakarta EE
  -> Construire les projets 1 et 2
  -> Préparer OCP Java SE 21

  Mois 6-12 (Phases 3 et 4)
  -> Microservices et Cloud
  -> Construire les projets 3 et 4
  -> Passer CKAD (Kubernetes)
  -> Contribuer à des projets open-source (Jakarta EE, Quarkus)

  Mois 12-18 (Phase 5)
  -> Projet bancaire final
  -> OCP Jakarta EE
  -> Créer un blog technique (documenter les apprentissages)
  -> Speaker dans un JUG local (crédibilité)
  -> Préparer les entretiens architecte

PROFIL GITHUB À CONSTRUIRE
  ├── bibliotheque-hexagonal/      <- Projet 1
  ├── ecommerce-jakartaee/         <- Projet 2
  ├── delivery-microservices/      <- Projet 3
  ├── bank-platform-ddd/           <- Projet 5 (vitrine)
  └── architecture-patterns/       <- Exemples de patterns

ENTRETIEN ARCHITECTE — QUESTIONS FRÉQUENTES
  1. Comment décomposez-vous un monolithe en microservices ?
  2. Expliquez-moi le pattern Saga et quand l'utiliser
  3. Comment gérez-vous les transactions distribuées ?
  4. Quelle stratégie de cache utilisez-vous et pourquoi ?
  5. Comment sécurisez-vous une API microservices ?
  6. Comment estimez-vous la capacité/scalabilité d'un système ?
  7. Montrez-moi un ADR que vous avez rédigé
  8. Comment gérez-vous le désaccord technique avec un développeur ?
  9. Quand choisissez-vous Event Sourcing ?
  10. Comment mesurez-vous le succès d'une architecture ?

═══════════════════════════════════════════════════════════════════
MOT DE FIN
═══════════════════════════════════════════════════════════════════

  Un architecte JEE expert n'est pas quelqu'un qui connaît
  toutes les APIs par cœur. C'est quelqu'un qui :

    [OK] Comprend les compromis (trade-offs) de chaque décision
    [OK] Sait dire "je ne sais pas" et trouver la réponse
    [OK] Communique clairement les problèmes complexes
    [OK] Reste humble et continue d'apprendre
    [OK] Code encore, tous les jours ou presque
    [OK] Met le succès du produit avant la beauté technique

  "La meilleure architecture est celle que votre équipe
   peut comprendre, maintenir et faire évoluer."

  Bonne route vers l'excellence architecturale !

═══════════════════════════════════════════════════════════════════
