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.
164 lines
8.0 KiB
Gherkin
164 lines
8.0 KiB
Gherkin
# language: fr
|
|
|
|
@api @navigation @geolocation @mvp
|
|
Fonctionnalité: Calcul ETA et notification contenus géolocalisés
|
|
|
|
En tant que système de recommandation
|
|
Je veux calculer le temps d'arrivée estimé (ETA) pour les contenus géolocalisés
|
|
Afin de déclencher la notification au bon moment (7 secondes avant)
|
|
|
|
Contexte:
|
|
Étant donné un utilisateur authentifié en mode voiture
|
|
Et la géolocalisation est activée et autorisée
|
|
|
|
# ============================================================================
|
|
# CALCUL ETA VITESSE NORMALE (≥5 km/h)
|
|
# ============================================================================
|
|
|
|
Scénario: Calcul ETA avec vitesse constante 50 km/h
|
|
Étant donné un contenu géolocalisé situé à 300m de l'utilisateur
|
|
Et l'utilisateur se déplace à 50 km/h en direction du point
|
|
Quand le système calcule l'ETA
|
|
Alors l'ETA estimé doit être d'environ 21 secondes
|
|
Et la notification doit être déclenchée dans 14 secondes (21s - 7s)
|
|
|
|
Scénario: Recalcul ETA en temps réel avec variation de vitesse
|
|
Étant donné un contenu géolocalisé situé à 500m
|
|
Et l'utilisateur se déplace initialement à 70 km/h
|
|
Et l'ETA initial est de 25 secondes
|
|
Quand l'utilisateur ralentit à 30 km/h
|
|
Alors l'ETA doit être recalculé à 60 secondes
|
|
Et le délai de notification doit être ajusté en conséquence
|
|
|
|
Scénario: Notification déclenchée exactement 7 secondes avant l'arrivée
|
|
Étant donné un contenu géolocalisé situé à 150m
|
|
Et l'utilisateur se déplace à 60 km/h
|
|
Et l'ETA calculé est de 9 secondes
|
|
Quand l'ETA atteint 7 secondes
|
|
Alors une notification push doit être envoyée
|
|
Et la notification doit contenir un compteur visuel de 7 à 1
|
|
Et un son de notification doit être joué
|
|
|
|
Scénario: Pas de notification si l'utilisateur dévie de la trajectoire
|
|
Étant donné un contenu géolocalisé situé à 200m au nord
|
|
Et l'utilisateur se déplace à 50 km/h en direction du contenu
|
|
Et l'ETA est de 14 secondes
|
|
Quand l'utilisateur change de direction vers l'est
|
|
Et la distance au contenu commence à augmenter
|
|
Alors la notification ne doit pas être déclenchée
|
|
Et l'ETA doit être invalidé
|
|
|
|
# ============================================================================
|
|
# CAS VITESSE LENTE (<5 km/h)
|
|
# ============================================================================
|
|
|
|
Scénario: Notification immédiate si vitesse <5 km/h et distance <50m
|
|
Étant donné un contenu géolocalisé situé à 30m
|
|
Et l'utilisateur se déplace à 3 km/h (piéton ou embouteillage)
|
|
Quand le système détecte la vitesse <5 km/h
|
|
Alors la notification doit être déclenchée immédiatement
|
|
Et le message doit indiquer "Contenu disponible à proximité"
|
|
|
|
Scénario: Pas de notification si vitesse <5 km/h mais distance >50m
|
|
Étant donné un contenu géolocalisé situé à 80m
|
|
Et l'utilisateur se déplace à 4 km/h
|
|
Quand le système évalue les conditions de notification
|
|
Alors aucune notification ne doit être envoyée
|
|
Et le système doit attendre que la distance soit <50m ou vitesse ≥5 km/h
|
|
|
|
Scénario: Basculement vitesse normale → lente avec recalcul
|
|
Étant donné un contenu géolocalisé situé à 100m
|
|
Et l'utilisateur se déplace à 40 km/h (ETA = 9s, notification dans 2s)
|
|
Quand l'utilisateur ralentit brutalement à 2 km/h (embouteillage)
|
|
Et la vitesse reste <5 km/h pendant 5 secondes
|
|
Et la distance est maintenant 85m
|
|
Alors le mode de calcul ETA doit basculer en "vitesse lente"
|
|
Et la notification immédiate ne doit pas être envoyée (distance >50m)
|
|
|
|
Scénario: Notification immédiate en approche lente continue
|
|
Étant donné un contenu géolocalisé situé à 60m
|
|
Et l'utilisateur se déplace à 3 km/h
|
|
Quand l'utilisateur atteint 45m du point (distance <50m)
|
|
Alors la notification doit être déclenchée immédiatement
|
|
Et le compteur visuel doit afficher "À proximité"
|
|
|
|
# ============================================================================
|
|
# GESTION TRAJECTOIRES COMPLEXES
|
|
# ============================================================================
|
|
|
|
Scénario: Route sinueuse avec distance GPS ≠ distance réelle
|
|
Étant donné un contenu géolocalisé situé à 250m à vol d'oiseau
|
|
Mais la route sinueuse fait 400m de trajet réel
|
|
Et l'utilisateur se déplace à 50 km/h
|
|
Quand le système calcule l'ETA
|
|
Alors l'ETA doit utiliser la distance GPS (250m) par défaut
|
|
Et l'ETA estimé doit être d'environ 18 secondes
|
|
Et une marge d'erreur de ±3 secondes doit être tolérée
|
|
|
|
Scénario: Contenu sur autoroute parallèle non accessible
|
|
Étant donné un contenu géolocalisé sur une autoroute parallèle à 100m
|
|
Et l'utilisateur roule sur une route secondaire sans accès direct
|
|
Et la distance GPS est de 100m mais l'accès réel est à 2 km
|
|
Quand le système détecte que l'utilisateur s'éloigne après 10 secondes
|
|
Alors la notification ne doit pas être déclenchée
|
|
Et le contenu doit être retiré de la file d'attente
|
|
|
|
# ============================================================================
|
|
# EDGE CASES & ERREURS
|
|
# ============================================================================
|
|
|
|
Scénario: GPS imprécis (précision >50m)
|
|
Étant donné un contenu géolocalisé situé à 150m
|
|
Et la précision GPS actuelle est de 65m
|
|
Quand le système calcule l'ETA
|
|
Alors l'ETA doit être calculé avec une marge d'erreur élevée
|
|
Et la notification doit être différée de 2 secondes supplémentaires
|
|
Et un flag "low_accuracy" doit être ajouté aux métriques
|
|
|
|
Scénario: Vitesse nulle (stationnement) avec contenu proche
|
|
Étant donné un contenu géolocalisé situé à 25m
|
|
Et l'utilisateur est à l'arrêt (vitesse = 0 km/h) depuis 10 secondes
|
|
Quand le système évalue les conditions
|
|
Alors aucune notification ne doit être envoyée automatiquement
|
|
Et le contenu doit être affiché dans la file d'attente manuelle
|
|
Et l'utilisateur peut le sélectionner manuellement
|
|
|
|
Scénario: Perte signal GPS pendant le calcul ETA
|
|
Étant donné un contenu géolocalisé avec ETA de 12 secondes
|
|
Et une notification prévue dans 5 secondes
|
|
Quand le signal GPS est perdu (tunnel)
|
|
Alors le calcul ETA doit être gelé à la dernière valeur connue
|
|
Et la notification doit être déclenchée selon l'ETA gelé
|
|
Et un fallback de 10 secondes max doit être appliqué
|
|
|
|
Scénario: Vitesse erratique (GPS instable)
|
|
Étant donné un contenu géolocalisé situé à 200m
|
|
Et les lectures GPS montrent : 50 km/h → 5 km/h → 60 km/h → 10 km/h en 10 secondes
|
|
Quand le système détecte une instabilité GPS
|
|
Alors l'ETA doit être calculé avec une moyenne mobile sur 5 secondes
|
|
Et la notification ne doit être déclenchée qu'avec une confiance >70%
|
|
|
|
# ============================================================================
|
|
# MÉTRIQUES & LOGS
|
|
# ============================================================================
|
|
|
|
Scénario: Logging des calculs ETA pour analytics
|
|
Étant donné un contenu géolocalisé avec notification déclenchée
|
|
Quand la notification est envoyée
|
|
Alors un événement analytics doit être loggé avec :
|
|
| distance_meters | 180 |
|
|
| speed_kmh | 55 |
|
|
| eta_seconds | 11.7 |
|
|
| notification_offset | 7 |
|
|
| gps_accuracy_meters | 12 |
|
|
| calculation_method | standard_eta |
|
|
Et la timestamp de notification doit être enregistrée
|
|
|
|
Scénario: Comparaison ETA prédit vs ETA réel
|
|
Étant donné un contenu géolocalisé avec ETA prédit de 15 secondes
|
|
Et une notification déclenchée à 8 secondes avant
|
|
Quand l'utilisateur atteint réellement le point
|
|
Alors l'ETA réel doit être calculé et comparé
|
|
Et l'écart doit être loggé pour amélioration de l'algorithme
|
|
Et si l'écart >5 secondes, un flag "prediction_error" doit être levé
|