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.
92 lines
4.4 KiB
Gherkin
92 lines
4.4 KiB
Gherkin
# language: fr
|
|
|
|
@api @audio-guides @cycling @transit @mvp
|
|
Fonctionnalité: Modes vélo et transports en commun complets
|
|
|
|
En tant qu'utilisateur à vélo ou en transports
|
|
Je veux une expérience adaptée à mon mode de déplacement
|
|
Afin de profiter des audio-guides en toute sécurité
|
|
|
|
Contexte:
|
|
Étant donné les caractéristiques des modes:
|
|
| Mode | Vitesse moyenne | Notifications | Auto-play |
|
|
| Vélo | 15-20 km/h | Audio priority| Optionnel |
|
|
| Transports | 30-40 km/h | Visuelles OK | Aux arrêts|
|
|
|
|
Scénario: Mode vélo avec notifications audio prioritaires
|
|
Étant donné un utilisateur "alice@roadwave.fr" en mode vélo à 18 km/h
|
|
Quand elle approche d'un point d'intérêt
|
|
Alors une notification audio est jouée (sécurité)
|
|
Et les notifications visuelles sont minimales
|
|
Et l'auto-play est optionnel (configurable)
|
|
Et un événement "CYCLING_MODE_POI_NOTIFICATION" est enregistré
|
|
|
|
Scénario: Mode transports avec détection des arrêts/stations
|
|
Étant donné un utilisateur "bob@roadwave.fr" en mode transports
|
|
Quand le système détecte un arrêt prolongé (station)
|
|
Alors l'audio-guide peut se déclencher à la station
|
|
Et les informations visuelles sont complètes
|
|
Et un événement "TRANSIT_STOP_DETECTED" est enregistré
|
|
|
|
Scénario: Adaptation du rayon de déclenchement en mode vélo
|
|
Étant donné un créateur "charlie@roadwave.fr" avec rayon adaptatif activé
|
|
Quand un utilisateur en mode vélo approche du POI
|
|
Alors le rayon est augmenté de 50% (anticipation)
|
|
Et le déclenchement se fait plus tôt
|
|
Et un événement "CYCLING_RADIUS_ADAPTED" est enregistré
|
|
|
|
Scénario: Gestion des tunnels en mode transports
|
|
Étant donné un utilisateur "david@roadwave.fr" en métro
|
|
Quand il entre dans un tunnel (perte GPS)
|
|
Alors la position est estimée selon la ligne de métro
|
|
Et les séquences continuent de se jouer normalement
|
|
Et un événement "TRANSIT_TUNNEL_MODE" est enregistré
|
|
|
|
Scénario: Sécurité en mode vélo - pause automatique si danger
|
|
Étant donné un utilisateur "eve@roadwave.fr" en mode vélo
|
|
Quand une accélération brusque est détectée (freinage)
|
|
Alors l'audio se met en pause automatiquement
|
|
Et reprend quand la vitesse se stabilise
|
|
Et un événement "CYCLING_SAFETY_PAUSE" est enregistré
|
|
|
|
Scénario: Mode transports avec synchronisation aux horaires
|
|
Étant donné un utilisateur "frank@roadwave.fr" en bus
|
|
Quand le système détecte les arrêts réguliers
|
|
Alors les séquences sont synchronisées aux stations
|
|
Et l'ETA est calculé selon les arrêts
|
|
Et un événement "TRANSIT_SCHEDULE_SYNC" est enregistré
|
|
|
|
Scénario: Statistiques spécifiques au mode vélo
|
|
Étant donné un utilisateur "grace@roadwave.fr" qui termine un audio-guide à vélo
|
|
Alors il voit des statistiques adaptées:
|
|
| Métrique | Valeur |
|
|
| Distance parcourue | 12.5 km |
|
|
| Temps de trajet | 45 min |
|
|
| Vitesse moyenne | 16.7 km/h |
|
|
| Dénivelé positif | 120m |
|
|
Et un événement "CYCLING_STATS_DISPLAYED" est enregistré
|
|
|
|
Scénario: Détection automatique changement vélo → transports
|
|
Étant donné un utilisateur "henry@roadwave.fr" en mode vélo
|
|
Quand il monte dans un bus avec son vélo
|
|
Alors le mode bascule automatiquement en "transports"
|
|
Et l'expérience s'adapte instantanément
|
|
Et un événement "MODE_SWITCH_CYCLING_TO_TRANSIT" est enregistré
|
|
|
|
Scénario: Mode vélo électrique avec détection
|
|
Étant donné un utilisateur "iris@roadwave.fr" sur un vélo électrique
|
|
Quand la vitesse moyenne est > 25 km/h (VAE)
|
|
Alors le système adapte les rayons de déclenchement
|
|
Et l'ETA est calculé avec vitesse VAE
|
|
Et un événement "EBIKE_MODE_DETECTED" est enregistré
|
|
|
|
Scénario: Métriques de performance modes vélo et transports
|
|
Étant donné que 10 000 parcours ont été effectués en vélo/transports
|
|
Alors les indicateurs suivants sont disponibles:
|
|
| Métrique | Vélo | Transports |
|
|
| Taux d'utilisation | 15% | 10% |
|
|
| Taux de complétion | 82% | 75% |
|
|
| Vitesse moyenne | 17km/h| 35km/h |
|
|
| Satisfaction utilisateur | 4.3/5 | 4.1/5 |
|
|
Et les métriques sont exportées vers le monitoring
|