Architecture applicative — cadrage et découpage métier
Avant de coder, posez-vous les bonnes questions.
Étudions le cas d'une application de prise de commande. Cette application permet à un utilisateur de parcourir le catalogue de produits, de vérifier la disponibilité en stock d'un article pour l'ajouter dans son panier, puis de payer le panier en toute sécurité afin de transformer le panier en commande confirmée (avec décrémentation des stocks et déclenchement de la livraison).
À travers ce scénario concret, explorons les questions fondamentales d'architecture applicative et leurs réponses.
Les questions à se poser (et les réponses)
❓ Quels sont les objectifs métiers et les scénarios critiques ?
Avant d'écrire la moindre ligne de code, il faut échanger avec le métier pour bien comprendre ce que le produit doit accomplir. On identifie le parcours utilisateur principal, c'est-à-dire celui qui a le plus de valeur ou qui ne doit jamais échouer. Ensuite, on écrit des règles strictes qui devront toujours être vraies dans le système.
🛒 Dans notre exemple :
- 🎯 Objectif métier : Permettre aux clients d'acheter des produits en ligne de manière autonome, fluide et sécurisée, tout en garantissant la disponibilité réelle des stocks.
- ⚡ Parcours critiques (Use Cases) :
- Ajout au panier : Sélectionner un article du catalogue, vérifier la disponibilité immédiate du stock et réserver temporairement la quantité.
- Paiement sécurisé : Transmettre le montant exact à la passerelle bancaire et attendre la confirmation sans risque de double débit.
- Création de commande : Transformer le panier payé en commande ferme, décrémenter le stock physique et notifier le centre logistique pour l'expédition.
- 🛡️ Règles métier absolues (Invariants) :
- Zéro survente : Impossible de valider un panier ou de créer une commande si la quantité demandée dépasse le stock disponible.
- Intégrité du prix : Le prix payé est celui affiché au moment de l'ajout au panier (verrouillage de prix pendant 15 minutes).
- Atomicité de la commande : Pas de commande créée sans paiement confirmé avec succès, et inversement aucun débit sans création immédiate d'une commande.
❓ Comment découper le domaine métier ?
On ne met pas tout dans une seule grosse boîte. En Domain-Driven Design (DDD), on découpe l'application en Bounded Contexts (contextes délimités). Chaque domaine possède ses propres règles, son propre vocabulaire (langage ubiquitaire) et son modèle de données dédié. Cela évite qu'une modification sur une partie du système vienne casser les autres.
🛒 Dans notre exemple — Définition de chaque domaine :
- 📦 Domaine Catalogue :
Définition : Il gère les fiches produits, les catégories, les descriptions, les prix publics et l'état des stocks disponibles. - 🛒 Domaine Panier :
Définition : Il gère la sélection temporaire d'articles par un utilisateur, applique les codes promotionnels et calcule le sous-total en temps réel. - 💳 Domaine Paiement :
Définition : Il orchestre la transaction bancaire avec un prestataire tiers (Stripe, PayPal, banque), valide le règlement et délivre une preuve de paiement. - 📋 Domaine Commande :
Définition : Il matérialise le contrat commercial définitif une fois le paiement validé. Il fige l'historique, gère les statuts (créée, en préparation, expédiée, livrée) et pilote la facturation.
🛠️ Mes outils dans cette phase de cadrage et conception
Pour aligner les équipes techniques et métiers, clarifier les concepts et formaliser la découpe du domaine sans ambiguïté, j'utilise une boîte à outils pragmatique :
Atelier collaboratif rapide avec des post-its (ou sur Miro/Mural). Métiers, développeurs et architectes posent sur une frise chronologique les événements métier clés du système (« ProduitAjouté », « PaiementAccepté », « CommandeCréée »). C'est l'outil idéal pour faire émerger naturellement les frontières des domaines.
👉 Voir l'exemple EventStormingFiches synthétiques décrivant pour chaque domaine son rôle, son langage ubiquitaire, ses règles internes et ses relations avec les domaines voisins (client/fournisseur, partenariat, couche anti-corruption). Cela évite les confusions sémantiques entre équipes.
👉 Voir l'exemple Bounded Context CanvasÉcriture de scénarios sous forme Étant donné / Quand / Alors validés avec les experts métier. Ils transforment les invariants en critères d'acceptation précis et non ambigus avant même l'écriture du premier test unitaire.
👉 Voir l'exemple Gherkin BDDModélisation légère en Diagrams-as-Code versionnés dans Git. Ils permettent de visualiser à haut niveau les flux entre domaines et avec les systèmes externes sans s'enfermer dans des schémas obsolètes.
👉 Voir l'exemple Diagramme C4