Étude de cas d'ingénierie · LeBonDon
Concevoir une plateforme multi-rôles testée pour l'inventaire, l'échange et la distribution sociale
LeBonDon gère le stock, les échanges et la distribution entre associations, entreprises et bénéficiaires. Son module LeBonDestock crée un flux B2B complet pour l'invendu à prix réduit.
- 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
- Spatie Permission
- Playwright
- GitHub Actions
- Docker
Preuves vérifiées
7 résultats vérifiés documentés ci-dessous.
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.
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.