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.
91 lines
4.4 KiB
Gherkin
91 lines
4.4 KiB
Gherkin
# language: fr
|
|
|
|
@api @profile @verification @mvp
|
|
Fonctionnalité: Badge compte vérifié pour créateurs authentiques
|
|
|
|
En tant que créateur officiel
|
|
Je veux obtenir un badge vérifié
|
|
Afin de prouver mon authenticité et gagner la confiance
|
|
|
|
Scénario: Demande de vérification par un créateur
|
|
Étant donné un créateur "MuseeDuLouvre" avec 1000+ abonnés
|
|
Quand il demande la vérification via "Paramètres > Demander la vérification"
|
|
Alors un formulaire de demande s'affiche:
|
|
| Champ requis | Exemple |
|
|
| Nom officiel | Musée du Louvre |
|
|
| Type d'organisation | Institution culturelle |
|
|
| Document officiel | KBIS / Statuts |
|
|
| Preuve d'identité | Carte d'identité |
|
|
| Site web officiel | louvre.fr |
|
|
| Compte social officiel | @MuseeLouvre (Twitter) |
|
|
Et la demande est soumise pour review
|
|
Et un événement "VERIFICATION_REQUEST_SUBMITTED" est enregistré
|
|
|
|
Scénario: Vérification par l'équipe RoadWave
|
|
Étant donné une demande de vérification reçue
|
|
Quand un modérateur examine le dossier
|
|
Alors il vérifie:
|
|
| Critère | Validation |
|
|
| Documents officiels | Authentiques |
|
|
| Correspondance identité | Confirmée |
|
|
| Site web officiel | Vérifié (DNS) |
|
|
| Réseaux sociaux | Cross-vérifiés |
|
|
| Activité sur RoadWave | Régulière (3+ mois) |
|
|
Et prend une décision dans les 7 jours
|
|
Et un événement "VERIFICATION_REVIEWED" est enregistré
|
|
|
|
Scénario: Attribution du badge vérifié
|
|
Étant donné une demande acceptée
|
|
Quand le badge est attribué
|
|
Alors un badge bleu "✓ Vérifié" s'affiche:
|
|
| Emplacement | Affichage |
|
|
| À côté du nom de profil | ✓ Musée du Louvre |
|
|
| Dans les résultats | Badge visible |
|
|
| Dans les commentaires | Badge visible |
|
|
Et une notification est envoyée: "Félicitations ! Votre compte est maintenant vérifié"
|
|
Et un événement "VERIFICATION_BADGE_GRANTED" est enregistré
|
|
|
|
Scénario: Avantages du compte vérifié
|
|
Étant donné un créateur vérifié
|
|
Alors il bénéficie de:
|
|
| Avantage | Détail |
|
|
| Badge bleu visible | Crédibilité accrue |
|
|
| Priorité dans les recherches | Meilleur ranking SEO |
|
|
| Statistiques avancées | Analytics détaillées |
|
|
| Support prioritaire | Réponse < 24h |
|
|
| Contenu mis en avant | Page "Créateurs vérifiés" |
|
|
Et un événement "VERIFIED_BENEFITS_DISPLAYED" est enregistré
|
|
|
|
Scénario: Révocation du badge pour violation
|
|
Étant donné un créateur vérifié "InstitutionX"
|
|
Quand il viole les CGU (contenu inapproprié)
|
|
Alors le badge est révoqué immédiatement
|
|
Et un email explique la raison
|
|
Et il peut faire appel de la décision
|
|
Et un événement "VERIFICATION_BADGE_REVOKED" est enregistré
|
|
|
|
Scénario: Renouvellement annuel de la vérification
|
|
Étant donné un créateur vérifié depuis 12 mois
|
|
Quand l'anniversaire de la vérification arrive
|
|
Alors une review automatique est lancée
|
|
Et des documents à jour peuvent être demandés
|
|
Et le badge reste actif pendant la review
|
|
Et un événement "VERIFICATION_RENEWAL_STARTED" est enregistré
|
|
|
|
Scénario: Badge spécial pour partenaires officiels
|
|
Étant donné un partenaire stratégique (Offices du Tourisme, Musées nationaux)
|
|
Alors un badge or "✓ Partenaire Officiel" est attribué
|
|
Et des privilèges supplémentaires sont accordés
|
|
Et un événement "OFFICIAL_PARTNER_BADGE_GRANTED" est enregistré
|
|
|
|
Scénario: Statistiques des comptes vérifiés
|
|
Étant donné que 150 comptes sont vérifiés
|
|
Alors les indicateurs suivants sont disponibles:
|
|
| Métrique | Valeur |
|
|
| Comptes vérifiés | 150 |
|
|
| % de la base créateurs | 1.5% |
|
|
| Demandes en attente | 45 |
|
|
| Taux d'acceptation | 65% |
|
|
| Temps moyen de vérification | 5 jours |
|
|
Et les métriques sont exportées vers le monitoring
|