5e5fcf4714
Réorganise la documentation du projet selon les principes du Domain-Driven Design (DDD) pour améliorer la cohésion, la maintenabilité et l'alignement avec l'architecture modulaire du backend. **Structure cible:** ``` docs/domains/ ├── README.md (Context Map) ├── _shared/ (Core Domain) ├── recommendation/ (Supporting Subdomain) ├── content/ (Supporting Subdomain) ├── moderation/ (Supporting Subdomain) ├── advertising/ (Generic Subdomain) ├── premium/ (Generic Subdomain) └── monetization/ (Generic Subdomain) ``` **Changements effectués:** Phase 1: Création de l'arborescence des 7 bounded contexts Phase 2: Déplacement des règles métier (01-19) vers domains/*/rules/ Phase 3: Déplacement des diagrammes d'entités vers domains/*/entities/ Phase 4: Déplacement des diagrammes flux/états/séquences vers domains/*/ Phase 5: Création des README.md pour chaque domaine Phase 6: Déplacement des features Gherkin vers domains/*/features/ Phase 7: Création du Context Map (domains/README.md) Phase 8: Mise à jour de mkdocs.yml pour la nouvelle navigation Phase 9: Correction automatique des liens internes (script fix-markdown-links.sh) Phase 10: Nettoyage de l'ancienne structure (regles-metier/, diagrammes/, features/) **Configuration des tests:** - Makefile: godog run docs/domains/*/features/ - scripts/generate-bdd-docs.py: features_dir → docs/domains **Avantages:** ✅ Cohésion forte: toute la doc d'un domaine au même endroit ✅ Couplage faible: domaines indépendants, dépendances explicites ✅ Navigabilité améliorée: README par domaine = entrée claire ✅ Alignement code/docs: miroir de backend/internal/ ✅ Onboarding facilité: exploration domaine par domaine ✅ Tests BDD intégrés: features au plus près des règles métier Voir docs/REFACTOR-DDD.md pour le plan complet.
309 lines
14 KiB
Gherkin
309 lines
14 KiB
Gherkin
# language: fr
|
||
Fonctionnalité: Paiement des créateurs
|
||
En tant que créateur monétisé
|
||
Je veux recevoir mes paiements mensuels de manière fiable
|
||
Afin d'être rémunéré pour mon travail
|
||
|
||
Contexte:
|
||
Étant donné que je suis un créateur avec la monétisation activée
|
||
Et que mon KYC est validé
|
||
|
||
Scénario: Seuil minimum de 50€ atteint - Paiement effectué
|
||
Étant donné que mes revenus du mois sont 73.45€
|
||
Quand le dernier jour du mois arrive
|
||
Alors mon solde de 73.45€ est transféré vers "en attente de paiement"
|
||
Et le paiement sera effectué le 15 du mois prochain
|
||
|
||
Scénario: Seuil minimum de 50€ non atteint - Report mois suivant
|
||
Étant donné que mes revenus du mois sont 32.17€
|
||
Quand le dernier jour du mois arrive
|
||
Alors mon solde de 32.17€ est reporté au mois suivant
|
||
Et je vois "Solde insuffisant pour paiement (<50€). Report mois prochain."
|
||
|
||
Scénario: Cumul sur plusieurs mois jusqu'à atteindre 50€
|
||
Étant donné que mes revenus sont:
|
||
| mois | revenus | solde cumulé |
|
||
| Janvier | 18.50€ | 18.50€ |
|
||
| Février | 22.30€ | 40.80€ |
|
||
| Mars | 15.70€ | 56.50€ |
|
||
Quand la fin du mois de mars arrive
|
||
Alors le solde cumulé de 56.50€ dépasse les 50€
|
||
Et un paiement de 56.50€ est effectué le 15 avril
|
||
|
||
Scénario: Calcul des revenus le dernier jour du mois
|
||
Étant donné que nous sommes le 31 janvier à 23h59
|
||
Quand le système calcule les revenus du mois
|
||
Alors une requête SQL agrège tous les revenus pub et premium
|
||
Et le solde final du mois est figé dans monthly_revenues
|
||
Et le compteur du mois en cours repart à 0€ le 1er février
|
||
|
||
Scénario: Période de traitement contestations 1-14 du mois
|
||
Étant donné que mes revenus de janvier sont calculés à 150.00€
|
||
Quand la période du 1-14 février arrive
|
||
Alors RoadWave analyse les éventuelles fraudes ou contestations
|
||
Et si une fraude est détectée, les revenus concernés sont retirés du solde
|
||
Et le solde final est validé le 14 février
|
||
|
||
Scénario: Virement SEPA le 15 du mois suivant
|
||
Étant donné que mes revenus de janvier validés sont 150.00€
|
||
Quand le 15 février arrive
|
||
Alors Mangopay initie un virement SEPA depuis mon e-wallet vers mon RIB
|
||
Et le statut du paiement passe à "En cours"
|
||
|
||
Scénario: Réception virement 16-18 du mois (1-3 jours SEPA)
|
||
Étant donné qu'un virement SEPA a été initié le 15 février
|
||
Quand 1-3 jours ouvrés s'écoulent
|
||
Alors je reçois le virement sur mon compte bancaire entre le 16 et 18 février
|
||
Et je peux consulter l'historique des paiements dans mon dashboard
|
||
|
||
Scénario: Virement SEPA gratuit pour comptes EU
|
||
Étant donné que mon RIB est français (IBAN FR)
|
||
Quand Mangopay effectue le virement
|
||
Alors aucun frais n'est prélevé (virement SEPA gratuit)
|
||
Et je reçois 100% du montant annoncé
|
||
|
||
Scénario: Virement international hors EU avec frais variables
|
||
Étant donné que je suis créateur expatrié avec RIB hors Union Européenne
|
||
Quand Mangopay effectue le virement international
|
||
Alors des frais variables s'appliquent selon le pays
|
||
Et les frais sont déduits du montant final
|
||
Et je vois le détail des frais dans mon historique
|
||
|
||
Scénario: E-wallet Mangopay automatique
|
||
Étant donné que mon KYC est validé
|
||
Quand mes revenus sont calculés
|
||
Alors les revenus sont automatiquement transférés vers mon e-wallet Mangopay
|
||
Et l'e-wallet est débité lors du virement SEPA vers mon RIB
|
||
Et je n'ai aucune action manuelle à faire
|
||
|
||
Scénario: Tableau de bord - Revenus pub temps réel
|
||
Étant donné que j'accède à mon tableau de bord créateur
|
||
Quand je consulte l'onglet "Revenus"
|
||
Alors je vois:
|
||
| métrique | valeur exemple |
|
||
| Revenus pub ce mois | 123.45€ |
|
||
| Revenus premium ce mois | 67.89€ |
|
||
| Solde disponible ce mois | 191.34€ |
|
||
| Prochain paiement | 15 mars 2025 |
|
||
Et ces valeurs sont mises à jour en temps réel (cache Redis, refresh 10 min)
|
||
|
||
Scénario: Tableau de bord - Solde en attente de paiement
|
||
Étant donné que mes revenus de janvier sont calculés et validés
|
||
Et que nous sommes le 10 février
|
||
Quand je consulte mon tableau de bord
|
||
Alors je vois:
|
||
| métrique | valeur exemple |
|
||
| Solde en attente | 150.00€ |
|
||
| Date de paiement | 15 février 2025 |
|
||
| Statut | En attente |
|
||
|
||
Scénario: Historique des virements permanents
|
||
Étant donné que je suis monétisé depuis 6 mois
|
||
Quand je consulte l'historique des paiements
|
||
Alors je vois la liste complète:
|
||
| date paiement | montant | statut | référence virement |
|
||
| 15/02/2025 | 150.00€ | Payé | MANGOPAY-ABC123 |
|
||
| 15/01/2025 | 123.50€ | Payé | MANGOPAY-XYZ789 |
|
||
| 15/12/2024 | 98.75€ | Payé | MANGOPAY-DEF456 |
|
||
| ... | ... | ... | ... |
|
||
|
||
Scénario: Export comptable CSV téléchargeable
|
||
Étant donné que je clique sur "Télécharger export comptable"
|
||
Quand le fichier CSV est généré
|
||
Alors je télécharge un fichier contenant:
|
||
```csv
|
||
Date,Revenus Pub,Revenus Premium,Total,Référence Virement,Statut
|
||
2025-02-15,89.50,60.50,150.00,MANGOPAY-ABC123,Payé
|
||
2025-01-15,78.30,45.20,123.50,MANGOPAY-XYZ789,Payé
|
||
2024-12-15,67.25,31.50,98.75,MANGOPAY-DEF456,Payé
|
||
```
|
||
Et je peux transmettre ce fichier à mon expert-comptable
|
||
|
||
Scénario: Échec virement - Tentative 1 échouée
|
||
Étant donné qu'un virement est initié le 15 février
|
||
Mais que mon RIB est invalide ou le compte est fermé
|
||
Quand Mangopay détecte l'échec
|
||
Alors le statut passe à "Échec - Retry programmé le 18 février"
|
||
Et je reçois un email m'alertant du problème
|
||
|
||
Scénario: Échec virement - Retry automatique J+3
|
||
Étant donné que le virement du 15 février a échoué
|
||
Quand le 18 février arrive (J+3)
|
||
Alors Mangopay tente automatiquement un nouveau virement
|
||
Et si le RIB est toujours invalide, le virement échoue à nouveau
|
||
|
||
Scénario: Échec virement - Retry automatique J+7
|
||
Étant donné que les 2 premières tentatives ont échoué
|
||
Quand le 22 février arrive (J+7)
|
||
Alors Mangopay tente une 3ème et dernière fois
|
||
Et si le virement échoue encore, la monétisation est suspendue
|
||
|
||
Scénario: Échec virement - Suspension monétisation après 3 échecs
|
||
Étant donné que les 3 tentatives de virement ont échoué
|
||
Quand le système détecte le 3ème échec
|
||
Alors ma monétisation est suspendue automatiquement
|
||
Et je reçois un email:
|
||
"""
|
||
Votre monétisation a été suspendue après 3 échecs de virement.
|
||
Veuillez mettre à jour votre RIB dans les paramètres de monétisation.
|
||
Votre solde de 150.00€ sera versé dès que le RIB sera valide.
|
||
"""
|
||
|
||
Scénario: Mise à jour RIB et réactivation paiement
|
||
Étant donné que ma monétisation est suspendue pour RIB invalide
|
||
Et que mon solde en attente est 150.00€
|
||
Quand je mets à jour mon RIB avec un compte valide
|
||
Alors Mangopay tente immédiatement un nouveau virement
|
||
Et si le virement réussit, ma monétisation est réactivée automatiquement
|
||
|
||
Scénario: Notification email lors de chaque paiement
|
||
Étant donné qu'un virement de 150.00€ est effectué le 15 février
|
||
Quand le virement est confirmé par Mangopay
|
||
Alors je reçois un email:
|
||
"""
|
||
💰 Paiement RoadWave effectué
|
||
|
||
Montant: 150.00€
|
||
Date: 15 février 2025
|
||
Référence: MANGOPAY-ABC123
|
||
Compte bancaire: FR76 **** **** **** **89
|
||
|
||
Ce virement devrait arriver sur votre compte sous 1-3 jours ouvrés.
|
||
Détails dans votre tableau de bord créateur.
|
||
"""
|
||
|
||
Scénario: Justification seuil 50€ - Éviter frais bancaires micro-sommes
|
||
Étant donné que Mangopay facture des frais fixes par virement
|
||
Et que les banques peuvent facturer des frais de réception
|
||
Quand un créateur génère seulement 5€/mois
|
||
Alors un virement mensuel coûterait proportionnellement trop cher
|
||
Et le seuil de 50€ garantit des frais proportionnels raisonnables
|
||
|
||
Scénario: Comparaison avec YouTube (seuil 100$)
|
||
Étant donné que YouTube fixe le seuil à 100$ (~90€)
|
||
Quand RoadWave fixe le seuil à 50€
|
||
Alors RoadWave est plus accessible pour petits créateurs
|
||
Et les paiements arrivent plus rapidement
|
||
|
||
Scénario: Comparaison avec Twitch (seuil 50$)
|
||
Étant donné que Twitch fixe le seuil à 50$ (~45€)
|
||
Quand RoadWave fixe le seuil à 50€
|
||
Alors le seuil est aligné sur Twitch
|
||
Et les créateurs comprennent facilement le système
|
||
|
||
Scénario: Comparaison avec Spotify (seuil 10€ mais délais longs)
|
||
Étant donné que Spotify a un seuil bas de 10€ mais verse tous les 3 mois
|
||
Quand RoadWave a un seuil de 50€ mais verse chaque mois
|
||
Alors les créateurs reçoivent leurs paiements plus régulièrement
|
||
Et la trésorerie est plus prévisible
|
||
|
||
Scénario: Relevé mensuel PDF automatique
|
||
Étant donné que mes revenus de janvier sont calculés
|
||
Quand le 1er février arrive
|
||
Alors un relevé mensuel PDF est généré automatiquement:
|
||
```
|
||
===== RELEVÉ ROADWAVE - JANVIER 2025 =====
|
||
|
||
Créateur: Jean Dupont
|
||
SIRET: 12345678901234
|
||
|
||
Revenus publicitaires: 89.50€
|
||
Revenus Premium: 60.50€
|
||
─────────────────────────────────
|
||
TOTAL: 150.00€
|
||
|
||
Écoutes complètes (gratuit): 29,833
|
||
Abonnés Premium actifs: 47
|
||
|
||
Paiement prévu: 15 février 2025
|
||
```
|
||
Et le PDF est téléchargeable depuis mon tableau de bord
|
||
|
||
Scénario: Conservation relevés 10 ans (obligation comptable)
|
||
Étant donné que je génère des revenus sur RoadWave
|
||
Quand je télécharge mes relevés mensuels
|
||
Alors je dois les conserver 10 ans (obligation légale France)
|
||
Et RoadWave conserve également une copie pendant 10 ans pour audit
|
||
|
||
Scénario: Dashboard admin - Monitoring paiements
|
||
Étant donné qu'un admin RoadWave consulte les paiements du mois
|
||
Quand il accède au dashboard admin
|
||
Alors il voit:
|
||
| métrique | valeur exemple |
|
||
| Créateurs payés ce mois | 1,247 |
|
||
| Montant total versé | 127,345€ |
|
||
| Paiements en attente | 34 |
|
||
| Échecs virements | 3 |
|
||
| Délai moyen réception (jours) | 1.8 |
|
||
|
||
Scénario: Alerte admin si taux échec >5%
|
||
Étant donné que 8% des virements du mois ont échoué
|
||
Quand le système détecte le taux d'échec élevé
|
||
Alors une alerte est envoyée à l'équipe technique:
|
||
"""
|
||
⚠️ Taux d'échec virements anormal: 8% (seuil: 5%)
|
||
Nombre échecs: 102 / 1,247 virements
|
||
Causes principales:
|
||
- RIB invalides: 67
|
||
- Comptes fermés: 23
|
||
- Autres erreurs: 12
|
||
"""
|
||
|
||
Scénario: Statistiques personnelles - Moyenne revenus sur 6 mois
|
||
Étant donné que je suis monétisé depuis 6 mois
|
||
Quand je consulte mes statistiques
|
||
Alors je vois:
|
||
| métrique | valeur |
|
||
| Revenus moyens/mois | 134.50€ |
|
||
| Meilleur mois | 189.00€ |
|
||
| Mois le plus bas | 87.30€ |
|
||
| Tendance | +12% ↗ |
|
||
Et cela m'aide à suivre ma progression
|
||
|
||
Scénario: Projection revenus annuels
|
||
Étant donné que mes revenus moyens sont 134.50€/mois
|
||
Quand je consulte les projections
|
||
Alors le système estime mes revenus annuels à ~1,614€
|
||
Et je peux anticiper mes déclarations fiscales
|
||
|
||
Scénario: Notification seuil symbolique 1000€ cumulés
|
||
Étant donné que mes revenus cumulés depuis inscription atteignent 1000€
|
||
Quand le paiement qui franchit ce seuil est effectué
|
||
Alors je reçois une notification:
|
||
"""
|
||
🎉 Félicitations ! Vous venez de dépasser 1000€ de revenus cumulés sur RoadWave !
|
||
Merci de contribuer à la plateforme avec votre contenu de qualité.
|
||
"""
|
||
|
||
Scénario: Performance calcul avec 100 000 créateurs monétisés
|
||
Étant donné que RoadWave a 100 000 créateurs monétisés
|
||
Quand le calcul des paiements du 15 du mois est lancé
|
||
Alors un job asynchrone traite les paiements par batch de 1000
|
||
Et tous les virements sont initiés en 2-4 heures
|
||
Et les serveurs Mangopay gèrent la charge sans problème
|
||
|
||
Scénario: Backup des données de paiement
|
||
Étant donné que les paiements sont critiques pour les créateurs
|
||
Quand un paiement est effectué
|
||
Alors les données sont sauvegardées dans PostgreSQL (principal)
|
||
Et répliquées vers une base de backup (replica)
|
||
Et une copie d'archive est stockée sur S3 (conservation 10 ans)
|
||
|
||
Scénario: Audit trail complet des paiements
|
||
Étant donné qu'un paiement est initié, traité et complété
|
||
Quand un audit est demandé
|
||
Alors tous les événements sont loggés:
|
||
| événement | timestamp | détails |
|
||
| Calcul revenus mois | 2025-01-31 23:59:00 | Montant: 150.00€ |
|
||
| Validation période fraude | 2025-02-14 23:59:00 | Aucune fraude détectée |
|
||
| Initiation virement | 2025-02-15 09:00:00 | Mangopay ref: ABC123 |
|
||
| Confirmation virement | 2025-02-16 14:30:00 | Reçu par banque créateur |
|
||
Et ces logs sont conservés 10 ans pour conformité
|
||
|
||
Scénario: Protection fraude - Détection pattern suspect
|
||
Étant donné qu'un créateur génère subitement 10 000€ de revenus en 1 mois
|
||
Alors que sa moyenne est de 50€/mois
|
||
Quand le système détecte cette anomalie
|
||
Alors le paiement est mis en attente pour vérification manuelle
|
||
Et l'équipe modération analyse le compte avant validation
|