Chapitre 16 : Projet Fil Rouge

Introduction

Ce chapitre est l'aboutissement de la formation. Il met en œuvre l'ensemble des techniques étudiées sur un cas concret : la conception complète d'un Système de Gestion de Commandes SaaS (Software as a Service).

16.1 Présentation du cas

16.1.1 Contexte

L'entreprise OrderFlow souhaite développer une plateforme SaaS de gestion de commandes destinée aux PME e-commerce. Le système doit permettre de :

Gérer les produits et le catalogue
Gérer les commandes de A à Z
Gérer les paiements et les remboursements
Gérer les expéditions et le suivi
Proposer des rapports et des analytics
Être multi-locataire (SaaS)

16.1.2 Acteurs

Diagramme en cours de génération...

16.1.3 Contraintes

Multi-locataire (SaaS)
Disponibilité 99.9%
RGPD conforme
Scalable horizontalement
Paiement via Stripe / PayPal
APIs REST + événements

16.2 Analyse des besoins

16.2.1 User Stories

Diagramme en cours de génération...

Exemple User Story détaillée :

Fonctionnalité: Passer commande
  En tant qu'acheteur
  Je veux passer une commande
  Afin de recevoir mes articles

  Scénario: Commande réussie
    Étant donné un panier avec des articles disponibles
    Quand je finalise ma commande
    Et que le paiement est accepté
    Alors la commande est créée avec le statut "confirmée"
    Et un email de confirmation est envoyé
    Et le stock est réservé

  Scénario: Paiement refusé
    Étant donné un panier avec des articles
    Quand le paiement est refusé
    Alors la commande n'est pas créée
    Et un message d'erreur s'affiche

16.2.2 Use Cases

UC-01 : Gérer les commandes

═══════════════════════════════════════
UC-01 : Gérer une commande
═══════════════════════════════════════
Acteur principal : Acheteur
Préconditions : Authentifié, panier non vide
Postconditions : Commande créée

Scénario nominal :
1. L'acheteur consulte son panier
2. Il saisit son adresse de livraison
3. Il choisit le mode de livraison
4. Il choisit le mode de paiement
5. Il paie
6. La commande est confirmée

Scénarios alternatifs :
A1. Panier vide → impossible de commander
A2. Adresse invalide → demander correction
A3. Paiement refusé → proposer alternative

16.3 Modélisation Merise (MCD / MLD)

16.3.1 MCD (Modèle Conceptuel de Données)

Diagramme en cours de génération...

16.3.2 MLD (Modèle Logique de Données)

-- Tables principales
CREATE TABLE Entreprise (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nom VARCHAR(255) NOT NULL,
    siret VARCHAR(14),
    email VARCHAR(255),
    plan VARCHAR(50) DEFAULT 'starter'
);

CREATE TABLE Produit (
    id INT PRIMARY KEY AUTO_INCREMENT,
    entreprise_id INT NOT NULL,
    reference VARCHAR(100) NOT NULL,
    nom VARCHAR(255) NOT NULL,
    prix DECIMAL(10,2) NOT NULL,
    stock INT DEFAULT 0,
    statut VARCHAR(50) DEFAULT 'actif',
    FOREIGN KEY (entreprise_id) REFERENCES Entreprise(id)
);

CREATE TABLE Commande (
    id INT PRIMARY KEY AUTO_INCREMENT,
    client_id INT NOT NULL,
    entreprise_id INT NOT NULL,
    numero VARCHAR(50) UNIQUE NOT NULL,
    date_creation DATETIME DEFAULT CURRENT_TIMESTAMP,
    statut VARCHAR(50) DEFAULT 'créée',
    total DECIMAL(10,2),
    adresse_livraison TEXT,
    FOREIGN KEY (client_id) REFERENCES Client(id),
    FOREIGN KEY (entreprise_id) REFERENCES Entreprise(id)
);

16.4 Event Storming

16.4.1 Big Picture

Diagramme en cours de génération...

16.4.2 Domain Events identifiés

Événement	Contexte	Policy associée
CompteEntrepriseCrée	Onboarding	Envoyer email bienvenue
CatalogueImporté	Catalogue	Vérifier qualité données
ProduitPublié	Catalogue	Indexer pour recherche
ProduitConsulté	Store	Recommandations
PanierModifié	Commande	Sauvegarder panier
CommandePassée	Commande	Démarrer saga
PaiementEffectué	Paiement	Notifier entreprise
StockRéservé	Stock	Mettre à jour inventaire
CommandePréparée	Expédition	Générer étiquette
ColisExpédié	Expédition	Envoyer tracking
CommandeLivrée	Expédition	Clôturer commande

16.5 DDD — Bounded Contexts et Aggregates

16.5.1 Context Map

Diagramme en cours de génération...

16.5.2 Aggregates

Aggregate : Commande

class Commande(Aggregate):
    def __init__(self, id, client_id, entreprise_id):
        self._id = id
        self._client_id = client_id
        self._entreprise_id = entreprise_id
        self._lignes: list[LigneCommande] = []
        self._statut = StatutCommande.CREE
        self._paiement_id = None
        self._expedition_id = None
    
    def ajouter_ligne(self, produit_id, quantite, prix):
        self._lignes.append(LigneCommande(produit_id, quantite, prix))
    
    def total(self):
        return sum(l.sous_total() for l in self._lignes)
    
    def confirmer(self):
        if not self._lignes:
            raise CommandeException("Commande vide")
        self._statut = StatutCommande.CONFIRMEE
        self.add_domain_event(CommandeConfirmée(self._id))
    
    def expedier(self, transporteur_id, numero_suivi):
        self._statut = StatutCommande.EXPEDIEE
        self.add_domain_event(CommandeExpédiée(self._id, numero_suivi))

16.6 Architecture C4

16.6.1 C1 — Contexte

Diagramme en cours de génération...

16.6.2 C2 — Conteneurs

Diagramme en cours de génération...

16.6.3 C3 — Composants (Service Commandes)

Diagramme en cours de génération...

16.7 BPMN — Processus Passer commande

Diagramme en cours de génération...

16.8 UML — Diagrammes détaillés

16.8.1 Diagramme de classes

Diagramme en cours de génération...

16.8.2 Diagramme de séquence — Saga Commande

Diagramme en cours de génération...

16.9 ADR (Architecture Decision Records)

ADR-001 : Architecture microservices

# ADR 001 : Architecture microservices pour OrderFlow

## Statut
Accepté

## Contexte
Application SaaS multi-locataire avec besoins de scalabilité
et équipes de développement multiples.

## Décision
Architecture microservices avec décomposition par contexte métier.

## Conséquences
Positives : Scalabilité, autonomie des équipes, déploiement indépendant
Négatives : Complexité distribuée, transactions gérées via Saga

ADR-002 : Kafka comme Event Bus

# ADR 002 : Apache Kafka pour la communication asynchrone

## Statut
Accepté

## Contexte
Besoins de communication événementielle entre services, event sourcing.

## Décision
Apache Kafka pour sa persistance, son rejeu d'événements,
et son intégration avec Kafka Streams.

## Conséquences
Positives : Découplage fort, traçabilité, rejeu
Négatives : Opérations complexes, latence minimale

ADR-003 : CQRS pour les rapports

# ADR 003 : CQRS pour le module Reporting

## Statut
Accepté

## Contexte
Les requêtes de reporting (>5s) impactent les opérations d'écriture.

## Décision
Implémentation de CQRS avec base de lecture dédiée pour les analytics.

## Conséquences
Positives : Performances lecture/écriture optimales
Négatives : Complexité, cohérence éventuelle

16.10 Documentation finale

16.10.1 Structure du projet

orderflow/
├── docs/
│   ├── index.md                    # Accueil
│   ├── architecture/
│   │   ├── context.md              # C1
│   │   ├── containers.md           # C2
│   │   ├── components/             # C3
│   │   └── decisions/              # ADR
│   ├── exigences/
│   │   ├── user-stories.md
│   │   └── use-cases.md
│   ├── modeles/
│   │   ├── mcd.md
│   │   └── mld.sql
│   ├── processus/
│   │   └── bpmn-commande.md
│   ├── api/
│   │   └── openapi.yaml
│   └── infrastructure/
│       └── deployment.md
├── src/
│   ├── services/
│   │   ├── commandes/
│   │   ├── paiement/
│   │   ├── stock/
│   │   ├── expedition/
│   │   └── notification/
│   └── shared/
└── README.md

16.10.2 Diagramme de synthèse

Diagramme en cours de génération...

Références

Tous les chapitres précédents (01-15)
Projet fil rouge — Synthèse complète
Merise, UML, C4, DDD, BPMN, ADR, Event Storming — Toutes les techniques

16 - Projet Fil Rouge : Système de Gestion de Commandes SaaS