Une marketplace nomme « vendeur » le compte connecté, l’entreprise signataire, la boutique visible et le bénéficiaire d’un reversement. Chaque équipe implémente alors sa définition, puis les statuts divergent dès le premier blocage de conformité.
En réalité, le découpage technique a suivi les équipes et les tables existantes sans expliciter les décisions métier. La plateforme partage des objets centraux, mais personne ne sait quel modèle fait autorité dans chaque situation.
Un premier signal faible apparaît quand deux écrans calculent différemment un même statut ; un second signal faible survient lorsque toute évolution exige une réunion entre catalogue, paiement et opérations. La douleur combine régressions, délais de livraison, incohérences financières et responsabilités diffuses.
Vous allez comprendre comment définir ces frontières avec notre expertise en performance et scalabilité marketplace, dans la continuité de la création de marketplace. Contre-intuitivement, un bounded context ne correspond ni automatiquement à une équipe, ni à un microservice, ni à une base de données.
Dans quels cas clarifier les bounded contexts marketplace
Le travail devient prioritaire lorsque les mêmes termes portent plusieurs règles, que des équipes doivent se coordonner pour chaque release ou que des corrections locales modifient silencieusement un autre parcours.
Reconnaître la collision des modèles
Produit, offre, vendeur, commande, paiement et retour semblent universels, mais leur sens dépend de la décision. Le support voit un dossier, la finance une créance et le moteur commercial une proposition vendable.
La collision se matérialise par des colonnes génériques, des enums interminables, des conditions selon le canal et des exports contradictoires. Elle indique plusieurs modèles entremêlés, pas seulement un manque de documentation.
Prioriser les zones coûteuses
Il serait disproportionné de cartographier tout le système avant d’agir. L’équipe commence par les décisions qui touchent argent, engagement client, conformité vendeur, disponibilité produit ou responsabilité réglementaire.
Le coût combine fréquence de coordination, gravité d’une erreur, difficulté de reprise et nombre d’interprétations. Un statut rarement modifié peut rester prioritaire s’il déclenche un reversement irréversible.
Partir des décisions plutôt que de l’organigramme
Une équipe décrit qui travaille aujourd’hui ; un contexte délimite où un modèle reste cohérent. Copier les services internes dans l’architecture fige une organisation temporaire et mélange souvent plusieurs logiques.
Nommer la décision protégée
Chaque frontière candidate répond à une question : qui peut vendre, quelle offre est publiable, quand une commande engage les parties, quel montant devient payable ou quel litige suspend le reversement.
Si deux capacités répondent avec les mêmes règles, données et rythme, elles peuvent rester ensemble. Si leurs décisions changent indépendamment ou emploient des définitions incompatibles, une séparation devient plausible.
Traiter l’organisation comme une contrainte
Disponibilité des compétences, responsabilités contractuelles et astreinte influencent l’implémentation sans dicter le modèle. Une petite équipe peut maintenir plusieurs contextes explicites dans un monolithe modulaire correctement structuré.
À l’inverse, trois équipes partageant la même base ne créent pas trois bounded contexts par leur seule existence. La frontière doit rester défendable lorsque l’organigramme change.
Faire émerger les différences de langage
Le langage ubiquitaire n’impose pas un vocabulaire unique à toute la marketplace. Il exige qu’un terme possède un sens précis dans un contexte et que les traductions soient explicites aux frontières.
Conduire des ateliers sur des cas réels
Les participants racontent onboarding, publication, commande, remboursement et clôture avec exemples récents. Le facilitateur relève synonymes, homonymes, règles implicites, changements d’état et moments où une autre équipe reprend la décision.
Par exemple, « actif » peut signifier contrat signé pour le juridique, offre visible pour le commerce et compte non suspendu pour les opérations. Chaque sens reçoit un nom contextualisé.
Refuser le glossaire sans comportement
Une définition utile relie le terme à des entrées, conditions, sorties et responsabilités. « Commande validée » reste ambigu tant que paiement, stock, fraude et engagement vendeur ne sont pas précisés.
Le vocabulaire vit dans scénarios, contrats et code, pas seulement dans un wiki. Une revue de pull request peut alors détecter qu’un concept étranger traverse la frontière sans traduction.
Inventorier décisions, invariants et temporalités
Une frontière devient testable quand elle protège des règles qui doivent rester vraies ensemble. L’inventaire relie commande métier, données nécessaires, résultat observable et délai de cohérence accepté.
Écrire les invariants avant les composants
Le ledger interdit qu’une écriture soit modifiée après comptabilisation ; l’offre interdit une quantité négative ; le reversement exige une balance justifiée. Ces règles révèlent une cohésion plus fiable que les noms de modules.
Chaque invariant précise le moment où il doit être vrai et l’autorité qui tranche. Une règle synchrone dans un contexte peut devenir une vérification asynchrone entre deux domaines.
Distinguer commande et observation
Décider qu’un vendeur est éligible appartient au domaine de conformité ; afficher cette éligibilité dans un cockpit relève d’une projection. Mélanger les deux transforme chaque besoin de lecture en dépendance d’écriture.
Les projections peuvent agréger plusieurs contextes sans devenir autorités. Elles tolèrent une fraîcheur annoncée, conservent provenance et reconstruisent leur état depuis les événements ou interfaces sources.
Séparer identité, compte et capacité à vendre
Le domaine vendeur concentre souvent personne, entreprise, contrat, boutique, utilisateur et bénéficiaire. Les distinguer évite qu’un blocage de connexion modifie abusivement le droit commercial de publier.
Isoler identité et accès
Identité gère authentification, sessions, facteurs et rattachements utilisateurs. Elle affirme qui agit, mais ne devrait pas décider seule si une entreprise satisfait les exigences du canal.
Le contexte consommateur reçoit un identifiant stable et des droits contextualisés. Il ne copie ni mot de passe, ni mécanisme de récupération, ni logique de sécurité qui appartient au fournisseur d’identité.
Modéliser l’éligibilité commerciale
Onboarding vendeur collecte preuves, contrat, coordonnées et validations, puis décide si une entité peut opérer sur un périmètre. La boutique visible devient une représentation, pas le dossier juridique complet.
Une suspension peut viser connexion, publication, prise de commande ou reversement selon sa cause. Un statut unique ACTIVE ou BLOCKED détruit cette nuance et propage des effets incontrôlés.
Distinguer produit, offre et représentation canal
Le produit décrit ce qui existe ; l’offre décrit qui vend, à quel prix et sous quelles conditions ; la représentation canal adapte catégories, attributs et contraintes de diffusion.
Garder le contenu produit cohérent
Identité produit, variantes, caractéristiques et médias évoluent selon des règles éditoriales ou industrielles. Leur cycle ne doit pas être capturé par une promotion commerciale de courte durée.
Le catalogue publie une version approuvée et signale les changements significatifs. Les offres référencent cette identité sans dupliquer toute sa description ni devenir propriétaires des attributs source.
Autoriser l’offre à varier indépendamment
Prix, stock vendable, délai, vendeur et conditions constituent une proposition commerciale contextualisée. Deux offres sur le même produit peuvent donc suivre des états et des politiques différentes.
La représentation canal traduit produit et offre selon une taxonomie externe, puis conserve les rejets. Elle ne réécrit pas le modèle source pour satisfaire une contrainte particulière.
Dissocier panier, commande et orchestration
Le panier explore une intention réversible ; la commande enregistre un engagement ; l’orchestration coordonne plusieurs participants. Les fusionner crée une transaction globale fragile et un historique difficile à expliquer.
Fixer le moment de l’engagement
Une commande capture lignes, prix, taxes, parties et conditions au moment convenu. Elle ne relit pas silencieusement le catalogue courant lorsque le service client consulte le passé.
L’acceptation vendeur, l’autorisation de paiement et la réservation de stock peuvent suivre des rythmes différents. Le modèle expose ces états sans prétendre qu’un seul booléen représente tout le parcours.
Orchestrer sans absorber les domaines
Le processus envoie commandes, attend réponses, gère échéances et compense lorsque nécessaire. Il référence les décisions de chaque contexte, mais ne recalcule pas lui-même fraude, montant ou disponibilité.
Son journal explique la progression d’une transaction et sa causalité. Si l’orchestrateur devient la seule autorité de toutes les règles, alors les frontières ne sont plus réellement autonomes.
Isoler paiement, ledger et reversement
Paiement acquéreur, écritures comptables et versement vendeur partagent des montants, mais répondent à des obligations, invariants et temporalités distincts. Une table financière unique masque ces différences critiques.
Séparer tentative et vérité comptable
Le paiement suit autorisation, capture, remboursement et échec du prestataire. Le ledger enregistre des écritures équilibrées et immuables qui justifient la position financière interne.
Un callback PSP peut être rejoué ou arriver en retard sans créer une seconde écriture. Identifiant, idempotence, montant, devise et référence métier rendent cette traduction contrôlable.
Calculer le payable avec ses propres règles
Reversement consolide ventes, commissions, remboursements, réserves et litiges selon une période. Il consomme des faits comptables, puis décide ce qui devient exigible pour chaque bénéficiaire.
En revanche, il ne devrait pas corriger une commande pour équilibrer son calcul. Toute divergence déclenche une exception vers la source responsable et conserve la preuve d’ajustement.
Modéliser expédition, retour et litige
Ces capacités suivent la commande après engagement, mais elles ne partagent pas toujours le même modèle. Un colis, une demande de retour et une réclamation représentent trois conversations différentes.
Faire du colis un agrégat logistique
Expédition gère allocation des lignes, transporteur, étiquette, événements de suivi et preuve de livraison. Une commande peut produire plusieurs colis sans perdre son identité commerciale.
Le contexte logistique reçoit adresse, lignes et promesse nécessaires, puis publie ses faits. Il ne devient pas propriétaire de la commande parce qu’il matérialise son exécution physique.
Séparer demande, décision et conséquence
Retour qualifie éligibilité, réception et état des biens ; litige instruit preuves et responsabilité ; remboursement exécute une conséquence financière. Leur coordination n’exige pas un modèle partagé.
Une même anomalie peut ouvrir plusieurs processus reliés par identifiants et causalité. La context map rend ces relations visibles sans confondre dossier support, décision commerciale et mouvement comptable.
Construire une context map exploitable
La carte ne se limite pas à des boîtes reliées par des flèches. Elle nomme les modèles, leurs relations, le sens des dépendances, les contrats et les tensions connues.
Qualifier amont et aval
Le contexte amont contrôle un modèle publié ; l’aval choisit comment le consommer. Cette asymétrie explique qui peut faire évoluer le contrat et qui supporte une traduction locale.
La relation précise cadence, garantie, version, délai de notification et procédure d’incident. Une flèche sans ces informations décrit une connexion, pas une dépendance gouvernable.
Choisir coopération ou protection
Deux équipes proches peuvent co-construire un langage partagé sur une zone stable. Un domaine stratégique exposé à un modèle externe préférera une couche anticorruption qui traduit explicitement les concepts.
Le choix dépend du pouvoir de négociation, du rythme de changement et du coût d’une contamination sémantique. Une traduction répétée peut signaler une mauvaise frontière ou un contrat insuffisant.
Versionner les décisions de cartographie
Chaque relation possède responsable, hypothèse, dette et date de revue. La carte évolue avec l’apprentissage, les partenaires, les volumes et les capacités réellement séparées.
Un diff de context map accompagne les décisions d’architecture importantes. Il montre quelle dépendance apparaît, disparaît ou change de sens avant que le code rende la modification coûteuse.
Attribuer l’autorité des données
Plusieurs contextes peuvent connaître le même identifiant sans partager la même représentation. L’autorité porte sur une décision ou un fait précis, jamais sur un mot générique comme client ou produit.
Écrire une matrice de propriété
Pour chaque donnée critique, la matrice indique qui crée, modifie, valide, publie et historise. Elle précise aussi les consommateurs, la fraîcheur attendue et le comportement lorsque la source manque.
Le catalogue possède la description approuvée ; l’offre possède prix et quantité ; la commande possède le snapshot engagé. Ces trois vérités coexistent parce qu’elles répondent à des temporalités différentes.
Éviter la base partagée comme contrat
Lire directement les tables d’un autre contexte contourne validations, permissions et cycle de changement. La dépendance paraît rapide jusqu’au premier renommage ou recalcul historique.
Une vue publiée peut servir de transition si son schéma, sa stabilité et sa fin sont explicites. Le consommateur ne reçoit jamais un droit général sur le stockage interne.
Concevoir les contrats entre domaines
Les frontières ont besoin d’interfaces intentionnelles : commandes pour demander, événements pour annoncer un fait et requêtes pour lire une projection. Chaque forme porte des attentes différentes.
Publier un langage d’intégration stable
Le contrat externe reste plus petit que le modèle interne et utilise des termes compris par l’aval. Il documente identifiants, états, invariants, erreurs, ordre et politique de compatibilité.
Une couche de traduction absorbe les nuances locales. Partager directement les classes du domaine économise quelques lignes, mais couple releases, stockage et vocabulaire entre équipes.
Prévoir échec, répétition et retard
Un événement peut être livré plusieurs fois, une réponse arriver après expiration et une dépendance devenir indisponible. Idempotence, corrélation, timeout, retry et compensation appartiennent donc au contrat opérationnel.
Les tests couvrent ancien producteur, nouveau consommateur et scénarios métier. La mise sous test des frontières marketplace empêche ensuite une dépendance interdite de revenir silencieusement.
Distinguer modèle et topologie technique
Un bounded context délimite un modèle ; le déploiement choisit des processus, dépôts et bases. Confondre ces niveaux force trop tôt une architecture distribuée ou laisse un monolithe sans frontières.
Commencer par un monolithe modulaire
Des modules, namespaces, interfaces et règles de dépendance peuvent rendre les contextes explicites dans un seul déploiement. Cette option réduit la charge réseau tout en préparant une extraction éventuelle.
Le choix monolithe modulaire ou microservices dépend ensuite de capacité, autonomie, exploitation et compétences disponibles, pas d’une équivalence mécanique avec le modèle DDD de conception stratégique.
Extraire sur des preuves de pression
Cadence indépendante, besoin de scalabilité, isolation réglementaire ou panne récurrente peuvent justifier un service autonome. La frontière déjà claire réduit alors les données et comportements à déplacer.
Si l’extraction multiplie appels synchrones et déploiements coordonnés, alors le contexte est probablement trop fin ou l’interface mal conçue. Le réseau révèle le couplage auparavant caché.
Tester puis réviser les frontières
La cartographie reste une hypothèse jusqu’à ce que des scénarios, métriques et changements réels l’éprouvent. Une bonne frontière diminue les coordinations sans déplacer la complexité vers les incidents.
Mesurer cohésion et couplage
Fréquence des changements conjoints, appels croisés, tables partagées, incidents multi-équipes et transactions distribuées fournissent des signaux. Aucun indicateur isolé ne décide automatiquement d’une séparation.
Le monitoring relie dépendances, latence, erreurs et reprise aux transactions métier. Une frontière théoriquement propre mais toujours indisponible avec son voisin doit être réexaminée.
Organiser une revue contradictoire
À chaque évolution majeure, une équipe tente de casser la carte avec cas limites, acquisitions, nouveaux canaux et obligations. Les exceptions répétées révèlent les modèles devenus trop larges.
La décision conserve hypothèses, alternatives et seuils de révision. La frontière n’est pas sacrée ; elle doit pouvoir fusionner, se scinder ou changer de relation avec une migration contrôlée.
Éviter les erreurs fréquentes de découpage
Les échecs viennent rarement d’un mauvais dessin initial seulement. Ils apparaissent surtout lorsque le dessin devient une vérité définitive, déconnectée du langage, des données et du run.
Ne pas créer un contexte par table
Une table représente un stockage, pas une capacité métier. Découper selon vendeur, adresse et statut produit des services minuscules qui doivent chatter pour chaque décision réelle.
En revanche, une base peut héberger plusieurs schémas logiques si les accès transverses sont interdits. L’autonomie se prouve par les contrats et invariants avant de se prouver par l’infrastructure.
Ne pas viser l’indépendance absolue
Une marketplace est un système de coopération : commande dépend d’offre, reversement dépend d’écritures et litige dépend de preuves. La carte rend ces relations maîtrisées, elle ne les efface pas.
Le but est de réduire les changements et pannes corrélés tout en conservant le parcours. Supprimer toute dépendance conduirait à dupliquer les faits et à créer plusieurs autorités concurrentes.
Plan d’action : cartographier la marketplace en six semaines
Le chantier commence sur un parcours à forte coordination, puis élargit les apprentissages. Six semaines suffisent pour produire une première carte opposable sans promettre une refonte complète.
Semaines 1 à 3 : découvrir les modèles
La première semaine collecte incidents, décisions et vocabulaire. La deuxième rejoue trois parcours réels avec métiers et développeurs. La troisième formule contextes candidats, invariants, données et responsables.
Les entrées, sorties, dépendances et temporalités rejoignent une context map versionnée. Les zones incertaines restent marquées comme hypothèses avec scénarios de validation, plutôt que maquillées en certitudes.
Semaines 4 à 6 : confronter et protéger
La quatrième semaine définit contrats et traductions. La cinquième mesure couplage puis écrit tests d’architecture. La sixième choisit un changement pilote, son rollback et ses preuves.
Le dossier final contient glossaires contextualisés, invariants, matrice d’autorité, relations, contrats, métriques et dette. Une date de revue garantit que la carte suivra les nouvelles décisions.
- Sélectionner un parcours où plusieurs équipes interprètent différemment vendeur, offre, commande, paiement ou litige, puis réunir les décisions réellement prises.
- Tracer événements, commandes, invariants et temporalités avant de nommer les contextes, afin que les frontières découlent des comportements observés.
- Attribuer l’autorité de chaque donnée critique et distinguer snapshot historique, projection de lecture, source modifiable et traduction destinée aux consommateurs.
- Qualifier chaque relation amont-aval, choisir coopération ou couche anticorruption, puis publier un contrat qui protège le langage de chaque domaine.
- Vérifier cohésion, fréquence des appels, pannes corrélées et changements conjoints avant de décider dépôt, base, processus ou extraction en microservice.
- Tester une évolution réelle, enregistrer les écarts et réviser la carte selon des preuves, avec responsable, échéance et stratégie de retour explicites.
Guides complémentaires et références primaires
Ces sources cadrent bounded contexts, context maps, limites de service et traduction entre modèles. Leur application à une marketplace exige ensuite des scénarios concrets sur vendeurs, transactions et finance.
Revenir aux définitions du DDD
La synthèse DDD d’Eric Evans rassemble les définitions et patterns de conception stratégique, notamment bounded context, ubiquitous language et context map, dans une ressource officielle librement disponible.
La présentation Bounded Context de Martin Fowler explique pourquoi un grand domaine nécessite plusieurs modèles cohérents et pourquoi leurs relations doivent être rendues explicites.
Les recommandations Microsoft sur les frontières de microservices proposent de confronter le découpage à la cohésion, aux appels bavards, à l’autonomie de déploiement et à l’intégrité des données.
Protéger les modèles aux interfaces
Le pattern officiel Anti-Corruption Layer d’AWS décrit une couche de médiation qui traduit la sémantique d’un contexte amont vers le modèle adapté au contexte aval.
La documentation AWS sur DDD et architecture hexagonale recommande une décomposition fondée sur la logique métier plutôt que sur les couches techniques, puis l’isolation du domaine derrière ports et adaptateurs.
Pour relier découverte et exécution, les fitness functions marketplace rendent les frontières vérifiables, tandis que le choix de topologie marketplace traite séparément le déploiement.
- Définir chaque contexte par son langage, ses décisions et ses invariants avant de choisir équipes, dépôts, bases ou processus de déploiement.
- Cartographier les relations amont-aval et protéger les différences sémantiques avec des contrats ou traductions plutôt qu’un modèle global partagé.
- Réviser les frontières à partir des changements conjoints, incidents, appels et scénarios métier, car le découpage reste une hypothèse évolutive.
Conclusion : rendre les frontières évolutives
Un bounded context utile ne reproduit pas l’organigramme. Il délimite un langage cohérent, protège des décisions et rend explicites les traductions nécessaires avec les autres domaines.
Vendeur, produit, offre, commande, paiement et litige peuvent partager des identifiants sans partager leurs modèles. Cette distinction évite qu’une modification locale redéfinisse silencieusement tout le parcours.
La context map devient crédible lorsqu’elle attribue données, contrats et responsabilités, puis survit à une évolution réelle. Les métriques et tests indiquent ensuite où fusionner, scinder ou renforcer.
Pour cartographier ces domaines et construire une trajectoire technique proportionnée, notre accompagnement en création de marketplace relie décisions métier, architecture, delivery et exploitation sans imposer une topologie prématurée.
