Exemples de livrables de cadrage DDD — Prise de commande

Cet article présente les livrables concrets produits lors de la phase de découverte et de modélisation du domaine pour notre application e-commerce de prise de commande.

🟧 1. EventStorming (Frise chronologique des événements métier)

L'atelier d'EventStorming rassemble les experts métier et les développeurs. On positionne sur une frise les événements au passé (en orange 🟧), les commandes déclencheuses (en bleu 🟦), les agrégats / entités (en jaune 🟨) et les règles / politiques (en violet 🟪).

Sortie concrète de l'atelier :

[👤 Client] 
   │
   ▼
🟦 [CommanderArticle] ──▶ 🟨 Panier ──▶ 🟧 [ArticleAjoutéAuPanier]
                                            │
                                            ▼ (Règle : Vérifier dispo)
                                       🟪 [Si stock insuffisant ➔ Notification]
                                            │
   ┌────────────────────────────────────────┘
   ▼
🟦 [ValiderPaiement] ──▶ 🟨 Paiement ──▶ 🟧 [PaiementAutorisé]
                                            │
                                            ▼ (Politique : Dès paiement validé)
                                       🟪 [Déclencher confirmation commande]
                                            │
   ┌────────────────────────────────────────┘
   ▼
🟦 [CréerCommande] ──▶ 🟨 Commande ──▶ 🟧 [CommandeConfirmée]
                                            │
                                            ├──▶ 🟧 [StockRéservéDéfinitivement]
                                            └──▶ 🟧 [OrdreExpéditionTransmis]

Bénéfice : En quelques heures, toute l'équipe visualise la chronologie exacte et identifie sans ambiguïté les 4 contextes délimités : Catalogue, Panier, Paiement et Commande.

🗺️ 2. Bounded Context Canvas (Fiche d'identité d'un domaine)

Le Canvas synthétise la responsabilité, les frontières et le langage ubiquitaire d'un contexte délimité. Voici l'exemple pour le Domaine Commande :

📋 Fiche Contexte : Domaine Commande (Order Context)

Rôle principal : Matérialiser le contrat d'achat immuable, orchestrer le cycle de vie de la commande et piloter la logistique et la facturation.
Langage Ubiquitaire (Glossaire) :
- Order (Commande) : Entité racine immuable dès sa validation.
- OrderLine (Ligne de commande) : Snapshot figé (intitulé, référence, prix unitaire au moment de l'achat).
- OrderStatus : Statuts stricts (CREATED, PAID, PREPARING, SHIPPED, DELIVERED, CANCELLED).
- Invoice (Facture) : Document comptable légal associé.
Invariants & Règles critiques :
- Aucune commande ne peut passer à l'état PAID sans jeton de transaction valide fourni par le domaine Paiement.
- Le montant total d'une commande ne peut plus être recalculé ou modifié après création.
Relations avec les domaines voisins (Context Map) :
- Panier (Upstream/Fournisseur) : Réception de l'événement PanierValidé avec le détail des lignes.
- Paiement (Upstream/Partenaire) : Dépendance synchrone ou asynchrone sur PaiementConfirmé.
- Logistique / Expédition (Downstream/Client) : Émission de l'événement CommandePrêtePourExpédition.

🥒 3. Exemples concrets & BDD (Scénarios Gherkin)

Les scénarios Given / When / Then formalisent les règles métier sous forme de spécifications exécutables, compréhensibles par le métier et directement automatisables en tests d'acceptation (Cucumber, Behave, Jest/Playwright).

Fonctionnalité: Validation de commande et sécurisation des stocks

  Contexte:
    Étant donné un produit "Casque Audio Pro" référencé à 199 € avec 3 unités en stock
    Et un client authentifié "Alice" avec un panier contenant 1 "Casque Audio Pro"

  Scénario: Commande réussie avec stock disponible et paiement validé
    Quand Alice procède au paiement de son panier de 199 € avec une carte valide
    Alors le paiement est accepté avec l'identifiant de transaction "TX-9876"
    Et une commande "CMD-001" est créée à l'état "PAID"
    Et le stock restant pour "Casque Audio Pro" passe à 2 unités
    Et une notification d'expédition est envoyée au centre logistique

  Scénario: Échec de commande en cas de refus bancaire (Zéro commande fantôme)
    Quand Alice tente de payer son panier avec une carte dont le solde est insuffisant
    Alors la passerelle de paiement refuse la transaction avec le motif "SOLDE_INSUFFISANT"
    Et aucune commande n'est créée dans le système
    Et le stock pour "Casque Audio Pro" reste inchangé à 3 unités
    Et le panier d'Alice reste disponible pour un nouvel essai

📐 4. Diagrammes C4 & Diagrams-as-Code (Mermaid / PlantUML)

Plutôt que des dessins figés dans des outils bureautiques, l'architecture est documentée sous forme de code textuel versionné avec les sources de l'application.

Diagramme de conteneurs (C4 Niveau 2) en Mermaid :

← Revenir à l'article Architecture applicative | Passer à l'implémentation de l'infrastructure →