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.
276 lines
13 KiB
Gherkin
276 lines
13 KiB
Gherkin
# language: fr
|
||
Fonctionnalité: Comportement auditeur pendant un live
|
||
En tant qu'auditeur
|
||
Je veux écouter un live avec une expérience stable et sécurisée
|
||
Afin de profiter du contenu en temps réel sans distraction
|
||
|
||
Contexte:
|
||
Étant donné que l'API RoadWave est disponible
|
||
Et que je suis connecté en tant qu'auditeur
|
||
Et qu'un créateur diffuse actuellement un live
|
||
|
||
Scénario: Buffer de synchronisation 15 secondes
|
||
Étant donné qu'un créateur parle en direct
|
||
Quand je rejoins le live
|
||
Alors j'entends l'audio avec un décalage de 15 secondes
|
||
Et ce buffer permet une stabilité optimale sur connexion 3G/4G
|
||
Et le buffer absorbe les fluctuations réseau courtes
|
||
|
||
Scénario: Justification buffer 15 secondes vs alternatives
|
||
Étant donné les différentes options de buffer possibles:
|
||
| Buffer | Stabilité 3G | Décalage perçu | Décision |
|
||
| 5s | Faible | Imperceptible | Rejeté |
|
||
| 10s | Moyenne | Faible | Rejeté |
|
||
| 15s | Excellente | Acceptable | Choisi |
|
||
| 20s+ | Très haute | Trop élevé | Rejeté |
|
||
Alors le buffer de 15 secondes est le meilleur compromis
|
||
Et la stabilité sur réseau mobile est prioritaire
|
||
|
||
Scénario: Continuation du live si sortie de zone géographique
|
||
Étant donné que j'écoute un live régional "Île-de-France"
|
||
Et que je suis situé à Paris
|
||
Quand je me déplace et sors de l'Île-de-France
|
||
Alors le live continue de jouer normalement
|
||
Et aucune coupure brutale ne se produit
|
||
Et l'écoute se termine naturellement
|
||
|
||
Scénario: Justification continuation hors zone
|
||
Étant donné que j'écoute activement un live
|
||
Quand je sors de la zone géographique ciblée
|
||
Alors le système ne coupe pas le live
|
||
Car une coupure brutale dégraderait l'expérience utilisateur
|
||
Et l'écoute engagée doit pouvoir se terminer naturellement
|
||
Mais après la fin du live, l'algorithme reprend le fonctionnement normal
|
||
|
||
Scénario: Après fin du live, algorithme normal reprend
|
||
Étant donné que j'ai écouté un live hors zone jusqu'à sa fin
|
||
Quand le live se termine
|
||
Alors l'algorithme de recommandation reprend son fonctionnement normal
|
||
Et je ne reçois plus de contenus hors de ma zone géographique actuelle
|
||
|
||
Scénario: Reconnexion rapide après coupure réseau (<90s)
|
||
Étant donné que j'écoute un live
|
||
Et que je perds ma connexion réseau pendant 30 secondes
|
||
Quand ma connexion revient
|
||
Alors je me reconnecte automatiquement au live
|
||
Et je reprends l'écoute au moment actuel du live
|
||
Et je ne reprends pas au buffer ancien (saut temporel transparent)
|
||
|
||
Scénario: Reconnexion après coupure réseau de 89 secondes
|
||
Étant donné que j'écoute un live
|
||
Et que je perds ma connexion réseau pendant 89 secondes
|
||
Quand ma connexion revient
|
||
Alors je me reconnecte au live en cours
|
||
Et je reprends au moment actuel
|
||
Car le seuil de 90 secondes n'est pas atteint
|
||
|
||
Scénario: Coupure réseau longue (≥90s) - Passage contenu suivant
|
||
Étant donné que j'écoute un live
|
||
Et que je perds ma connexion réseau pendant 90 secondes ou plus
|
||
Quand ma connexion revient
|
||
Alors je vois le message "Live en cours perdu, passage au contenu suivant"
|
||
Et l'algorithme me propose un contenu normal (non-live)
|
||
Et je ne rejoins pas le live précédent
|
||
|
||
Scénario: Saut temporel transparent lors de reconnexion
|
||
Étant donné que j'écoute un live au timestamp 00:05:00
|
||
Et que je perds ma connexion pendant 45 secondes
|
||
Quand je me reconnecte
|
||
Alors je reprends l'écoute au timestamp actuel du live (environ 00:05:45)
|
||
Et le saut de 45 secondes est transparent
|
||
Et je ne réentends pas les 45 secondes manquées
|
||
|
||
Scénario: Like disponible pendant le live (véhicule arrêté)
|
||
Étant donné que j'écoute un live
|
||
Et que mon véhicule est à l'arrêt
|
||
Quand je clique sur le bouton cœur ❤️
|
||
Alors un like est enregistré
|
||
Et mes jauges d'intérêt augmentent de +2% selon les tags du live
|
||
Et le créateur voit son compteur de likes s'incrémenter en temps réel
|
||
|
||
Scénario: Like désactivé pendant le live (véhicule en mouvement)
|
||
Étant donné que j'écoute un live
|
||
Et que mon véhicule est en mouvement
|
||
Quand j'essaie d'accéder aux interactions
|
||
Alors le bouton cœur est désactivé
|
||
Et je vois le message "Interactions disponibles uniquement véhicule à l'arrêt"
|
||
Car la sécurité routière est prioritaire
|
||
|
||
Scénario: Abonnement au créateur pendant le live (véhicule arrêté)
|
||
Étant donné que j'écoute un live d'un créateur non suivi
|
||
Et que mon véhicule est à l'arrêt
|
||
Quand je clique sur "S'abonner"
|
||
Alors l'abonnement est enregistré
|
||
Et mes jauges d'intérêt augmentent de +5% selon les tags du créateur
|
||
Et je recevrai des notifications pour ses prochains lives
|
||
|
||
Scénario: Skip disponible pendant le live
|
||
Étant donné que j'écoute un live
|
||
Quand je clique sur le bouton "Skip" (suivant)
|
||
Alors je quitte le live immédiatement
|
||
Et l'algorithme me propose le contenu suivant
|
||
Et je ne peux pas revenir au live via "Précédent"
|
||
|
||
Scénario: Bouton "Précédent" désactivé pendant un live
|
||
Étant donné que j'écoute un live
|
||
Quand je regarde les contrôles de lecture
|
||
Alors le bouton "Précédent" est désactivé (grisé)
|
||
Car il n'y a pas de sens sur un flux temps réel
|
||
Et je ne peux pas revenir en arrière dans un live
|
||
|
||
Scénario: Chat en direct jamais disponible (décision définitive)
|
||
Étant donné que j'écoute un live
|
||
Quand je cherche une fonctionnalité de chat
|
||
Alors aucun bouton de chat n'est disponible
|
||
Et aucune interface de messagerie n'est présente
|
||
Car cette fonctionnalité ne sera jamais implémentée
|
||
|
||
Scénario: Message explicatif sur absence de chat
|
||
Étant donné que j'essaie de chercher comment discuter pendant un live
|
||
Quand j'accède à l'aide ou aux FAQ
|
||
Alors je vois le message:
|
||
"""
|
||
💬 Les discussions ne sont pas disponibles sur RoadWave pour garantir votre sécurité en voiture et éviter le harcèlement.
|
||
|
||
RoadWave privilégie l'écoute passive pour:
|
||
- Votre sécurité au volant (pas de distraction)
|
||
- Votre bien-être (pas de harcèlement, toxicité)
|
||
- Une expérience audio apaisante
|
||
"""
|
||
|
||
Scénario: Réactions emoji jamais disponibles (décision définitive)
|
||
Étant donné que j'écoute un live
|
||
Quand je cherche des réactions emoji ou boutons interactifs
|
||
Alors aucune réaction emoji n'est disponible
|
||
Car cette fonctionnalité ne sera jamais implémentée
|
||
Et seuls les likes explicites sont autorisés (véhicule arrêté)
|
||
|
||
Scénario: Justification absence chat et réactions
|
||
Étant donné les raisons de l'absence de chat:
|
||
| Raison | Justification |
|
||
| Sécurité routière | Pas de distraction en voiture (focus UX) |
|
||
| Harcèlement | Évite contenu haineux, insultes, trolling |
|
||
| Modération | Pas de coût modération temps réel (impossible à scale) |
|
||
| Simplicité | Écoute passive = expérience uniforme |
|
||
| Bien-être | Évite toxicité, harcèlement (fléau réseaux sociaux) |
|
||
| Juridique | Pas de risque contentieux modération chat (DSA EU) |
|
||
| Différenciation | Positionnement "audio safe" vs plateformes toxiques |
|
||
Alors cette décision est définitive et non négociable
|
||
Et RoadWave se positionne comme une plateforme d'écoute passive sécurisée
|
||
|
||
Scénario: Compteur d'auditeurs en temps réel visible
|
||
Étant donné que j'écoute un live
|
||
Quand je regarde l'interface
|
||
Alors je vois le nombre d'auditeurs simultanés "247 auditeurs en direct"
|
||
Et ce compteur se met à jour toutes les 10 secondes
|
||
Et cela donne une indication de la popularité du live
|
||
|
||
Scénario: Indicateur "En direct" clair
|
||
Étant donné que j'écoute un live
|
||
Alors je vois clairement un badge rouge "🔴 EN DIRECT"
|
||
Et je comprends immédiatement que c'est un flux temps réel
|
||
Et pas un contenu enregistré
|
||
|
||
Scénario: Pas de barre de progression sur live
|
||
Étant donné que j'écoute un live
|
||
Quand je regarde les contrôles de lecture
|
||
Alors il n'y a pas de barre de progression
|
||
Car on ne peut pas se déplacer dans un flux temps réel
|
||
Et seule la durée écoulée est affichée (ex: "23:45 écoulées")
|
||
|
||
Scénario: Transition fluide live vers contenu suivant
|
||
Étant donné que j'écoute un live
|
||
Quand le live se termine naturellement
|
||
Alors le délai de transition habituel de 2 secondes démarre
|
||
Et le contenu suivant est annoncé normalement
|
||
Et l'expérience est cohérente avec les contenus classiques
|
||
|
||
Scénario: Notification de fin de live
|
||
Étant donné que j'écoute un live
|
||
Quand le créateur arrête le live
|
||
Alors j'entends "Ce live se termine dans 5... 4... 3... 2... 1"
|
||
Et je vois le message "Live terminé"
|
||
Et je suis notifié que le replay sera disponible sous peu
|
||
|
||
Scénario: Qualité audio adaptative selon connexion
|
||
Étant donné que j'écoute un live en 4G
|
||
Et que ma connexion se dégrade vers 3G
|
||
Quand la bande passante diminue
|
||
Alors le player HLS natif adapte automatiquement la qualité
|
||
Et le buffer de 15 secondes absorbe les fluctuations
|
||
Et l'écoute reste fluide sans coupure
|
||
|
||
Scénario: Consommation data pendant écoute live
|
||
Étant donné que j'écoute un live en Opus 48 kbps
|
||
Quand j'écoute pendant 1 heure
|
||
Alors je consomme environ 21.6 MB de data
|
||
Et cette information peut être affichée dans les paramètres
|
||
Et l'utilisateur peut être averti si réseau cellulaire
|
||
|
||
Scénario: Tunnel ou coupure réseau courte (<15s)
|
||
Étant donné que j'écoute un live
|
||
Et que je passe dans un tunnel pendant 10 secondes
|
||
Quand je ressors du tunnel
|
||
Alors le buffer de 15 secondes a absorbé la coupure
|
||
Et l'écoute reprend sans interruption perceptible
|
||
Et je n'ai même pas remarqué la coupure
|
||
|
||
Scénario: Notifications désactivables pour les lives
|
||
Étant donné que je suis abonné à un créateur
|
||
Et que je reçois des notifications de ses lives
|
||
Quand j'accède aux paramètres de notification
|
||
Alors je peux désactiver spécifiquement les notifications "Live en direct"
|
||
Et je continue à recevoir les autres notifications
|
||
Et cela me permet de contrôler les interruptions
|
||
|
||
Scénario: Statistiques d'écoute personnelles après un live
|
||
Étant donné que j'ai écouté un live pendant 45 minutes
|
||
Quand je consulte mon historique d'écoute
|
||
Alors je vois l'entrée "[DIRECT] [Titre du live]"
|
||
Et la durée d'écoute "45 min"
|
||
Et la date/heure de diffusion
|
||
Et un lien vers le replay si disponible
|
||
|
||
Plan du Scénario: Reconnexion selon durée de coupure
|
||
Étant donné que j'écoute un live
|
||
Et que je perds ma connexion pendant <duree_coupure> secondes
|
||
Quand ma connexion revient
|
||
Alors le comportement est <comportement>
|
||
|
||
Exemples:
|
||
| duree_coupure | comportement |
|
||
| 10 | Reconnexion au live en cours |
|
||
| 30 | Reconnexion au live en cours |
|
||
| 60 | Reconnexion au live en cours |
|
||
| 89 | Reconnexion au live en cours |
|
||
| 90 | Passage au contenu suivant |
|
||
| 120 | Passage au contenu suivant |
|
||
|
||
Plan du Scénario: Actions disponibles selon état véhicule
|
||
Étant donné que j'écoute un live
|
||
Et que mon véhicule est <etat_vehicule>
|
||
Quand j'essaie d'effectuer l'action <action>
|
||
Alors le résultat est <resultat>
|
||
|
||
Exemples:
|
||
| etat_vehicule | action | resultat |
|
||
| arrêté | Like | Autorisé |
|
||
| arrêté | Abonnement | Autorisé |
|
||
| arrêté | Skip | Autorisé |
|
||
| en mouvement | Like | Bloqué |
|
||
| en mouvement | Abonnement | Bloqué |
|
||
| en mouvement | Skip | Autorisé |
|
||
|
||
Plan du Scénario: Interactions jamais disponibles
|
||
Étant donné que j'écoute un live
|
||
Quand je cherche l'interaction <interaction>
|
||
Alors elle est <disponibilite>
|
||
Car <raison>
|
||
|
||
Exemples:
|
||
| interaction | disponibilite | raison |
|
||
| Chat en direct | Jamais disponible | Sécurité routière + modération impossible |
|
||
| Réactions emoji | Jamais disponible | Sécurité routière + distraction |
|
||
| Précédent | Jamais disponible | Pas de sens sur flux temps réel |
|
||
| Seek (avancer) | Jamais disponible | Pas de sens sur flux temps réel |
|