Aller au contenu
Alex ALAVO

Étude de cas d'ingénierie · LeBonDon

Fiabiliser une plateforme multi-rôles pour dons, inventaire et déstockage

LeBonDon structure les dons, stocks, échanges et flux de déstockage B2B entre acteurs aux rôles différents, avec permissions serveur et parcours critiques testés.

Problème

La plateforme sert des acteurs avec des permissions et des objectifs opérationnels différents. Le flux de déstockage traverse la soumission par l'entreprise, l'évaluation par l'administrateur et l'achat par l'association, ce qui rend la justesse à travers les rôles essentielle.

Solution

Laravel porte le domaine et la couche de services, React et Inertia fournissent l'interface interactive, Spatie Permission contrôle les rôles, et Playwright vérifie le flux métier complet via des objets de page réutilisables et des fixtures authentifiées.

Preuve

Autorisation multi-rôles

Discuter d'un système similaire
Rôle
Architecture full-stack, conception de la couche de services, autorisation, implémentation frontend, tests automatisés et workflow qualité CI.

Responsabilités du système

  • SaaS
  • Tests

Technologies

  • Laravel
  • React
  • TypeScript
  • Inertia
  • +4

Certains détails métier, opérationnels ou techniques ont été généralisés pour respecter la confidentialité client.

Progression0%

Aperçu

Les associations, entreprises et bénéficiaires opèrent avec des permissions et des objectifs différents, et le flux de déstockage traverse la soumission par l'entreprise, l'évaluation par l'administrateur et l'achat par l'association.

  • Gérer l'inventaire et les dons.
  • Soutenir les échanges entre associations.
  • Suivre la distribution aux bénéficiaires.
  • Permettre le déstockage par les entreprises.
  • Appliquer des permissions spécifiques à chaque rôle.
  • Protéger les flux critiques de bout en bout.

Le problème

La plateforme sert des acteurs avec des permissions et des objectifs opérationnels différents. Le flux de déstockage traverse la soumission par l'entreprise, l'évaluation par l'administrateur et l'achat par l'association, ce qui rend la justesse à travers les rôles essentielle.

Contraintes qui ont façonné le système

  • Plusieurs types d'acteurs.
  • Règles d'autorisation complexes.
  • La logique métier ne doit pas s'accumuler dans les contrôleurs.
  • Le comportement du frontend et du backend doit rester cohérent.
  • Le flux critique nécessitait des tests de navigateur reproductibles.
  • Le déploiement nécessitait des portes de qualité automatisées.

Architecture du système

Laravel porte le domaine et la couche de services, React et Inertia fournissent l'interface interactive, Spatie Permission contrôle les rôles, et Playwright vérifie le flux métier complet via des objets de page réutilisables et des fixtures authentifiées.

Diagramme de l'architecture du système : Navigateur (React + Inertia), Application Laravel, Couche de services, Spatie Permission, Base de données, Suite E2E Playwright.

client

Navigateur (React + Inertia)

Décisions d'ingénierie clés

Couche de services stricte

Accepté

La logique métier ne doit pas s'accumuler dans les contrôleurs.

Garder les contrôleurs concentrés sur les préoccupations HTTP et déplacer les opérations métier vers des services.

Pourquoi

  • Tests facilités.
  • Complexité des contrôleurs réduite.
  • Meilleure réutilisation.
  • Propriété claire du comportement du domaine.

Modèle d'objets de page E2E

Accepté

Le flux critique de déstockage nécessitait des tests de navigateur reproductibles.

Représenter les zones destinées à l'utilisateur via des objets de page et des fixtures réutilisables.

Pourquoi

  • Réduire la duplication de sélecteurs.
  • Améliorer la lisibilité des tests.
  • Soutenir une exécution CI stable.

Autorisation basée sur les rôles

Accepté

La plateforme sert des acteurs avec des permissions différentes et des règles d'autorisation complexes.

Centraliser les permissions via un package d'autorisation éprouvé et des vérifications côté serveur.

Pourquoi

  • Règles d'accès cohérentes.
  • Audit et maintenance facilités.

Points clés de l'implémentation

  • Module de déstockage B2B LeBonDestock pour l'invendu à prix réduit.
  • Flux de soumission par l'entreprise, d'évaluation par l'administrateur et d'achat par l'association.
  • Application des permissions spécifiques à chaque type d'acteur.

Qualité et exploitation

Tests

  • Couverture de tests PHPUnit.
  • Couverture end-to-end Playwright pour le flux de déstockage.

Exploitation

  • Conteneurisation Docker.
  • Déploiement sur Railway.
  • Workflow CI GitHub Actions.

Résultats et preuves

  • Fait d'implémentation

    Autorisation multi-rôles

  • Fait d'implémentation

    Couche de services stricte

    Contrôleurs allégés grâce à l'extraction en services

  • Capacité observable

    Flux de déstockage complet implémenté et testé

  • Fait d'implémentation

    Couverture qualité PHPUnit et Playwright

  • Fait d'implémentation

    Modèle d'objets de page pour les tests E2E

  • Fait d'implémentation

    Workflow CI GitHub Actions

  • Capacité observable

    Workflow de déploiement Docker et Railway

Leçons tirées du système

  • Les workflows critiques doivent être testés du point de vue de l'utilisateur.
  • L'autorisation doit se situer côté serveur, même quand l'interface masque des actions.
  • Une couche de services est utile quand elle reflète des responsabilités du domaine, pas quand elle ne fait qu'ajouter des fichiers.

Projet similaire

Un système comme LeBonDon à structurer ?

Si vous avez un workflow, une intégration ou une plateforme qui devient difficile à maintenir, on peut clarifier le problème et définir une trajectoire fiable.