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.
240 lines
14 KiB
Gherkin
240 lines
14 KiB
Gherkin
# language: fr
|
|
|
|
@api @audio-guides @geolocation @mvp
|
|
Fonctionnalité: Détection automatique du mode de déplacement
|
|
|
|
En tant qu'utilisateur
|
|
Je veux que l'application détecte automatiquement mon mode de déplacement
|
|
Afin d'adapter l'expérience audio-guide (voiture, piéton, vélo, transports)
|
|
|
|
Contexte:
|
|
Étant donné que le système utilise les capteurs suivants pour la détection:
|
|
| Capteur | Utilisation |
|
|
| GPS (vitesse) | Vitesse de déplacement |
|
|
| Accéléromètre | Détection de la marche |
|
|
| Gyroscope | Détection de mouvements |
|
|
| Bluetooth | Connexion CarPlay/Android Auto |
|
|
| Activité (CoreMotion) | walking, running, cycling, automotive |
|
|
|
|
Scénario: Détection automatique du mode voiture
|
|
Étant donné un utilisateur "alice@roadwave.fr" en déplacement
|
|
Quand le système détecte les indicateurs suivants:
|
|
| Indicateur | Valeur |
|
|
| Vitesse GPS | 45 km/h |
|
|
| Accélération longitudinale | Typique d'une voiture|
|
|
| Bluetooth connecté | CarPlay |
|
|
| Activity Recognition | automotive |
|
|
| Stabilité du mouvement | Haute |
|
|
Alors le mode de déplacement "voiture" est sélectionné avec confiance: 95%
|
|
Et l'interface passe en mode voiture:
|
|
| Caractéristique | État |
|
|
| Notifications visuelles | Minimales |
|
|
| Notifications audio | Prioritaires |
|
|
| Affichage des distances | Mètres + temps ETA |
|
|
| Auto-play au point d'intérêt | Activé |
|
|
Et un événement "TRAVEL_MODE_DETECTED_CAR" est enregistré
|
|
Et la métrique "travel_mode.detected.car" est incrémentée
|
|
|
|
Scénario: Détection automatique du mode piéton
|
|
Étant donné un utilisateur "bob@roadwave.fr" en déplacement
|
|
Quand le système détecte les indicateurs suivants:
|
|
| Indicateur | Valeur |
|
|
| Vitesse GPS | 4 km/h |
|
|
| Accéléromètre | Pattern de marche |
|
|
| Fréquence de pas | 110 pas/min |
|
|
| Activity Recognition | walking |
|
|
| Bluetooth connecté | Non |
|
|
Alors le mode de déplacement "piéton" est sélectionné avec confiance: 92%
|
|
Et l'interface passe en mode piéton:
|
|
| Caractéristique | État |
|
|
| Notifications visuelles | Complètes |
|
|
| Navigation libre | Activée |
|
|
| Affichage carte | Complet |
|
|
| Auto-play publicité | Autorisé |
|
|
Et un événement "TRAVEL_MODE_DETECTED_WALKING" est enregistré
|
|
Et la métrique "travel_mode.detected.walking" est incrémentée
|
|
|
|
Scénario: Détection automatique du mode vélo
|
|
Étant donné un utilisateur "charlie@roadwave.fr" en déplacement
|
|
Quand le système détecte les indicateurs suivants:
|
|
| Indicateur | Valeur |
|
|
| Vitesse GPS | 18 km/h |
|
|
| Accéléromètre | Vibrations régulières|
|
|
| Pattern de mouvement | Cyclique |
|
|
| Activity Recognition | cycling |
|
|
| Variations de vitesse | Moyennes |
|
|
Alors le mode de déplacement "vélo" est sélectionné avec confiance: 88%
|
|
Et l'interface passe en mode vélo:
|
|
| Caractéristique | État |
|
|
| Notifications visuelles | Limitées |
|
|
| Notifications audio | Prioritaires |
|
|
| Affichage des distances | Mètres |
|
|
| Auto-play au point d'intérêt | Optionnel |
|
|
Et un événement "TRAVEL_MODE_DETECTED_CYCLING" est enregistré
|
|
Et la métrique "travel_mode.detected.cycling" est incrémentée
|
|
|
|
Scénario: Détection automatique du mode transports en commun
|
|
Étant donné un utilisateur "david@roadwave.fr" en déplacement
|
|
Quand le système détecte les indicateurs suivants:
|
|
| Indicateur | Valeur |
|
|
| Vitesse GPS | 35 km/h avec arrêts |
|
|
| Pattern d'arrêts | Régulier (stations) |
|
|
| Accéléromètre | Stationnaire par moments|
|
|
| Précision GPS | Variable (tunnels) |
|
|
| Activity Recognition | automotive + stationary |
|
|
Alors le mode de déplacement "transports" est sélectionné avec confiance: 80%
|
|
Et l'interface passe en mode transports:
|
|
| Caractéristique | État |
|
|
| Notifications visuelles | Complètes |
|
|
| Auto-play aux stations | Activé |
|
|
| Affichage carte | Complet |
|
|
| Prise en compte des tunnels | Activée |
|
|
Et un événement "TRAVEL_MODE_DETECTED_TRANSIT" est enregistré
|
|
Et la métrique "travel_mode.detected.transit" est incrémentée
|
|
|
|
Scénario: Changement dynamique de mode détecté (voiture → piéton)
|
|
Étant donné un utilisateur "eve@roadwave.fr" en mode voiture
|
|
Et il roule à 50 km/h
|
|
Quand l'utilisateur se gare et sort de la voiture:
|
|
| Temps | Vitesse | Activity | Bluetooth |
|
|
| T+0s | 50 km/h | automotive | CarPlay |
|
|
| T+30s | 0 km/h | stationary | CarPlay |
|
|
| T+60s | 0 km/h | stationary | Déconnecté|
|
|
| T+90s | 4 km/h | walking | Non |
|
|
Alors le mode bascule automatiquement de "voiture" à "piéton"
|
|
Et une notification discrète s'affiche: "Mode piéton activé"
|
|
Et l'interface s'adapte instantanément au mode piéton
|
|
Et un événement "TRAVEL_MODE_CHANGED" est enregistré avec transition: "car_to_walking"
|
|
Et la métrique "travel_mode.transition.car_to_walking" est incrémentée
|
|
|
|
Scénario: Changement dynamique de mode détecté (piéton → vélo)
|
|
Étant donné un utilisateur "frank@roadwave.fr" en mode piéton
|
|
Et il marche à 4 km/h
|
|
Quand l'utilisateur monte sur un vélo:
|
|
| Temps | Vitesse | Activity | Pattern |
|
|
| T+0s | 4 km/h | walking | Marche |
|
|
| T+10s | 8 km/h | cycling | Cyclique |
|
|
| T+20s | 15 km/h | cycling | Cyclique |
|
|
| T+30s | 18 km/h | cycling | Cyclique stable|
|
|
Alors le mode bascule automatiquement de "piéton" à "vélo"
|
|
Et une notification s'affiche: "Mode vélo activé"
|
|
Et les paramètres audio sont ajustés pour réduire les notifications visuelles
|
|
Et un événement "TRAVEL_MODE_CHANGED" est enregistré avec transition: "walking_to_cycling"
|
|
Et la métrique "travel_mode.transition.walking_to_cycling" est incrémentée
|
|
|
|
Scénario: Détection ambiguë avec faible confiance
|
|
Étant donné un utilisateur "grace@roadwave.fr" en déplacement
|
|
Quand le système détecte des indicateurs contradictoires:
|
|
| Indicateur | Valeur |
|
|
| Vitesse GPS | 12 km/h |
|
|
| Activity Recognition | unknown |
|
|
| Accéléromètre | Pattern irrégulier |
|
|
| Confiance de détection | 45% |
|
|
Alors le mode actuel est conservé (pas de changement)
|
|
Et une icône d'interrogation s'affiche discrètement
|
|
Et l'utilisateur peut forcer manuellement le mode via un menu rapide
|
|
Et un événement "TRAVEL_MODE_UNCERTAIN" est enregistré
|
|
Et la métrique "travel_mode.uncertain" est incrémentée
|
|
|
|
Scénario: Forçage manuel du mode de déplacement
|
|
Étant donné un utilisateur "henry@roadwave.fr" en mode auto-détecté "piéton"
|
|
Mais il est en réalité en voiture (passager)
|
|
Quand l'utilisateur ouvre le menu rapide et sélectionne "Mode voiture"
|
|
Alors le mode "voiture" est forcé manuellement
|
|
Et l'auto-détection est temporairement désactivée pour 30 minutes
|
|
Et un événement "TRAVEL_MODE_FORCED_MANUAL" est enregistré avec ancienMode: "walking", nouveauMode: "car"
|
|
Et la métrique "travel_mode.manual_override" est incrémentée
|
|
Et après 30 minutes, l'auto-détection se réactive automatiquement
|
|
|
|
Scénario: Mode stationnaire détecté (arrêt prolongé)
|
|
Étant donné un utilisateur "iris@roadwave.fr" en mode voiture
|
|
Et il est arrêté à un feu rouge depuis 2 minutes
|
|
Quand le système détecte:
|
|
| Indicateur | Valeur |
|
|
| Vitesse GPS | 0 km/h |
|
|
| Activity Recognition | stationary |
|
|
| Durée d'immobilité | 120 secondes |
|
|
| Bluetooth connecté | CarPlay |
|
|
Alors le mode reste "voiture" (pas de changement)
|
|
Mais un flag "stationary" est activé
|
|
Et l'audio en cours continue de jouer normalement
|
|
Et aucun nouveau contenu n'est déclenché automatiquement
|
|
Et un événement "TRAVEL_MODE_STATIONARY" est enregistré
|
|
Et la métrique "travel_mode.stationary" est incrémentée
|
|
|
|
Scénario: Reprise du mouvement après mode stationnaire
|
|
Étant donné un utilisateur "jack@roadwave.fr" en mode "voiture stationary"
|
|
Et il est arrêté depuis 3 minutes
|
|
Quand le système détecte:
|
|
| Temps | Vitesse | Activity |
|
|
| T+0s | 0 km/h | stationary |
|
|
| T+5s | 10 km/h | automotive |
|
|
| T+10s | 30 km/h | automotive |
|
|
Alors le flag "stationary" est désactivé
|
|
Et le mode "voiture" normal est restauré
|
|
Et la logique de déclenchement automatique des audio-guides est réactivée
|
|
Et un événement "TRAVEL_MODE_RESUMED" est enregistré
|
|
Et la métrique "travel_mode.resumed" est incrémentée
|
|
|
|
Scénario: Gestion des permissions de localisation et capteurs
|
|
Étant donné un utilisateur "kate@roadwave.fr" qui lance l'application
|
|
Quand les permissions suivantes sont refusées:
|
|
| Permission | État |
|
|
| Localisation GPS | Refusée |
|
|
| Motion & Fitness | Refusée |
|
|
Alors l'auto-détection du mode est désactivée
|
|
Et un message s'affiche: "Pour bénéficier de l'expérience optimale, activez les permissions de localisation et mouvement"
|
|
Et un bouton "Activer les permissions" redirige vers les Réglages
|
|
Et l'utilisateur doit sélectionner manuellement son mode de déplacement
|
|
Et un événement "TRAVEL_MODE_PERMISSIONS_DENIED" est enregistré
|
|
Et la métrique "travel_mode.permissions_denied" est incrémentée
|
|
|
|
Scénario: Optimisation de la batterie avec détection adaptative
|
|
Étant donné un utilisateur "luke@roadwave.fr" avec batterie < 20%
|
|
Quand le mode économie d'énergie est activé
|
|
Alors la fréquence de détection du mode est réduite:
|
|
| Mode normal | Mode économie d'énergie |
|
|
| Toutes les 5s | Toutes les 30s |
|
|
Et l'utilisation du GPS est optimisée (requêtes moins fréquentes)
|
|
Et l'accéléromètre et gyroscope sont consultés moins souvent
|
|
Et la précision de détection peut être légèrement réduite
|
|
Et un événement "TRAVEL_MODE_BATTERY_SAVER" est enregistré
|
|
Et la métrique "travel_mode.battery_saver.enabled" est incrémentée
|
|
|
|
Scénario: Historique des modes de déplacement pour statistiques
|
|
Étant donné un utilisateur "mary@roadwave.fr" qui utilise l'application depuis 1 mois
|
|
Quand l'utilisateur accède à "Mon compte > Statistiques > Modes de déplacement"
|
|
Alors l'utilisateur voit un graphique avec répartition:
|
|
| Mode | Temps total | Pourcentage |
|
|
| Voiture | 15h 30min | 45% |
|
|
| Piéton | 12h 10min | 35% |
|
|
| Vélo | 5h 20min | 15% |
|
|
| Transports | 1h 40min | 5% |
|
|
Et des insights sont affichés: "Vous utilisez principalement RoadWave en voiture"
|
|
Et les données sont conservées de manière agrégée pour respecter le RGPD
|
|
|
|
Scénario: Métriques de performance de la détection
|
|
Étant donné que le système traite 100 000 détections de mode par heure
|
|
Quand les métriques de performance sont collectées
|
|
Alors les indicateurs suivants sont respectés:
|
|
| Métrique | Valeur cible |
|
|
| Temps de détection du mode | < 100ms |
|
|
| Précision de détection (voiture) | > 95% |
|
|
| Précision de détection (piéton) | > 90% |
|
|
| Précision de détection (vélo) | > 85% |
|
|
| Taux de transitions incorrectes | < 5% |
|
|
| Consommation batterie par détection | < 0.01% |
|
|
Et les métriques sont exportées vers le système de monitoring
|
|
Et des alertes sont déclenchées si la précision < 80%
|
|
|
|
Scénario: A/B testing des algorithmes de détection
|
|
Étant donné que le système teste 2 algorithmes de détection:
|
|
| Algorithme | Description |
|
|
| A | Basé sur CoreMotion uniquement |
|
|
| B | Combinaison capteurs + ML |
|
|
Quand un utilisateur "nathan@roadwave.fr" est assigné au groupe B
|
|
Alors l'algorithme B est utilisé pour la détection
|
|
Et les métriques de précision sont tracées séparément par algorithme
|
|
Et les événements incluent le tag "algorithm_version: B"
|
|
Et après analyse, l'algorithme le plus performant est déployé à 100%
|