Concevoir une marketplace multi-acteurs sans dupliquer toute la logique métier

Cartographier les responsabilités avant les écrans

La liste des rôles ne suffit pas. Pour chaque étape, il faut identifier qui peut proposer, accepter, préparer, remettre, annuler, rembourser et arbitrer. Une même personne peut cumuler plusieurs rôles, tandis qu’une organisation peut déléguer certaines actions à ses employés.

Cette cartographie révèle les zones de conflit : qui est responsable d’un stock incorrect, quand le vendeur devient créancier, qui supporte un remboursement et quelles preuves sont nécessaires. Ces décisions sont métier et juridiques avant d’être techniques.

• Décrire les capacités plutôt qu’un simple nom de rôle.
• Associer chaque action à une responsabilité.
• Identifier les conflits et les voies d’arbitrage.

Séparer le noyau métier de ses projections

La commande, le produit, le paiement et la livraison possèdent une identité commune. Le vendeur voit la préparation et son solde ; l’acheteur voit le suivi et ses recours ; le support voit les événements nécessaires au diagnostic. Il ne s’agit pas de trois commandes différentes, mais de trois projections d’un même état.

Le serveur applique les règles et produit des vues filtrées. Les applications mobiles et tableaux de bord orchestrent l’expérience sans décider seules si une transition est autorisée. Cette séparation évite de recopier la logique critique dans plusieurs clients qui n’évoluent pas au même rythme.

Exprimer les autorisations au niveau des objets

Un contrôle qui vérifie seulement le rôle vendeur autorise trop largement. Il faut aussi vérifier que le vendeur appartient à la boutique concernée, que la commande contient ses articles et que l’action correspond à l’état courant. Les autorisations combinent ainsi rôle, relation, ressource et contexte.

La politique refuse par défaut et s’applique côté serveur à chaque requête. Les boutons masqués améliorent l’interface, mais ne protègent rien. Une matrice de tests couvre les accès verticaux, entre rôles, et horizontaux, entre deux boutiques ou deux clients.

• Vérifier la relation avec chaque ressource.
• Refuser par défaut les combinaisons inconnues.
• Tester les accès croisés entre organisations.

Faire de la commande une machine d’état partagée

Une commande passe par des états explicites : créée, confirmée, payée, acceptée, préparée, remise, livrée, annulée ou remboursée. Les transitions indiquent leur auteur, leur date, leur motif et les conditions nécessaires. Une modification directe du statut est interdite.

Les sous-commandes permettent de répartir une transaction entre plusieurs vendeurs sans perdre la vision client. La commande principale agrège le total et l’expérience ; chaque vendeur gère uniquement sa partie. Les événements mettent à jour les projections, notifications et tableaux de bord.

Modéliser l’argent comme un flux distinct

Le paiement du client, la commission, le montant dû au vendeur, les frais, le remboursement et le versement sont des mouvements différents. Les confondre dans un champ payé rend les réconciliations et litiges presque impossibles. Chaque mouvement possède un identifiant, un montant, une devise et une relation avec la transaction métier.

Le prestataire de paiement peut gérer l’encaissement et les comptes connectés, mais la plateforme reste responsable de son propre registre et de la compréhension de son modèle. Les appels sensibles utilisent des clés d’idempotence et les webhooks sont vérifiés, rejouables et traités sans créer de doublons.

Prévoir support, litiges et corrections

Le parcours nominal cache le vrai coût d’exploitation. Un client change d’adresse, un vendeur n’a plus le produit, un paiement arrive en retard ou une livraison est contestée. Le support doit voir une chronologie compréhensible et agir par commandes contrôlées plutôt qu’en modifiant directement la base.

Une correction crée un nouvel événement, conserve l’ancienne valeur et explique son motif. Les actions sensibles demandent parfois une double validation. Cette traçabilité protège les utilisateurs, facilite la réconciliation financière et transforme les incidents récurrents en améliorations produit.

Faire évoluer un rôle sans dupliquer le produit

Une nouvelle interface commence par réutiliser les mêmes capacités et événements. Si un besoin devient spécifique, on ajoute une commande ou une projection au noyau plutôt qu’une branche parallèle de la logique. Les contrats API versionnés permettent aux clients d’évoluer progressivement.

Les tests de scénario traversent plusieurs rôles : achat, acceptation partielle, livraison, litige puis remboursement. Ils vérifient à la fois l’état, les permissions et les mouvements financiers. Une marketplace reste cohérente lorsque chaque acteur voit une partie différente de la réalité sans que le système possède plusieurs vérités.

• Centraliser les invariants, distribuer les vues.
• Versionner commandes et événements.
• Tester les scénarios de bout en bout avec plusieurs rôles.
• Mesurer les corrections manuelles et leurs causes.