refactor(docs): réorganiser la documentation selon principes DDD
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.
This commit is contained in:
jpgiannetti
@@ -0,0 +1,111 @@
|
||||
# language: fr
|
||||
|
||||
@api @audio-guides @advertising @mvp
|
||||
Fonctionnalité: Système de publicités complet
|
||||
|
||||
En tant que plateforme
|
||||
Je veux gérer un système publicitaire équilibré et non intrusif
|
||||
Afin de monétiser la plateforme tout en préservant l'expérience utilisateur
|
||||
|
||||
Contexte:
|
||||
Étant donné les règles publicitaires:
|
||||
| Règle | Valeur |
|
||||
| Durée max publicité | 30s |
|
||||
| Fréquence max par heure | 3 |
|
||||
| Skip autorisé après | 5s |
|
||||
| Mode auto-play | Piéton only |
|
||||
| Premium sans pub | Oui |
|
||||
|
||||
Scénario: Insertion intelligente de publicité entre séquences
|
||||
Étant donné un utilisateur "alice@roadwave.fr" Free en mode piéton
|
||||
Quand elle termine l'écoute d'une séquence
|
||||
Et marche vers la suivante (temps de trajet: 5 min)
|
||||
Alors une publicité peut être insérée pendant le trajet
|
||||
Et elle ne coupe jamais une séquence en cours
|
||||
Et un événement "AD_INSERTED_BETWEEN_SEQUENCES" est enregistré
|
||||
|
||||
Scénario: Ciblage géographique et contextuel des publicités
|
||||
Étant donné un utilisateur "bob@roadwave.fr" près de restaurants
|
||||
Et ses intérêts incluent "Gastronomie" à 80%
|
||||
Quand une publicité doit être affichée
|
||||
Alors le système priorise les restaurants à proximité
|
||||
Et match les intérêts de l'utilisateur
|
||||
Et un événement "AD_TARGETED" est enregistré avec score_match: 95
|
||||
|
||||
Scénario: Format publicitaire audio + visuel
|
||||
Étant donné une publicité pour le "Café Le Parisien"
|
||||
Quand elle est diffusée
|
||||
Alors l'audio est joué (max 30s)
|
||||
Et une carte visuelle s'affiche avec:
|
||||
| Élément | Contenu |
|
||||
| Logo | Image du commerce |
|
||||
| Offre spéciale | -10% avec code ROAD10 |
|
||||
| Distance | À 50m |
|
||||
| Bouton CTA | [Y aller] [Sauvegarder]|
|
||||
Et un événement "AD_DISPLAYED_FULL" est enregistré
|
||||
|
||||
Scénario: Facturation au CPM et CPC pour annonceurs
|
||||
Étant donné un commerce "Le Parisien" avec budget pub
|
||||
Quand sa publicité est diffusée 1000 fois (impressions)
|
||||
Alors il est facturé selon le modèle CPM: 5€ pour 1000 impressions
|
||||
Quand 50 utilisateurs cliquent sur "Y aller"
|
||||
Alors il est facturé selon le CPC: 0.50€ par clic
|
||||
Et un événement "AD_BILLING_CALCULATED" est enregistré
|
||||
|
||||
Scénario: Dashboard annonceur avec statistiques détaillées
|
||||
Étant donné un annonceur "Restaurant Tokyo" connecté
|
||||
Quand il consulte son dashboard
|
||||
Alors il voit les métriques en temps réel:
|
||||
| Métrique | Valeur |
|
||||
| Impressions (7 jours) | 2 450 |
|
||||
| Taux d'écoute complète | 38% |
|
||||
| Clics "Y aller" | 125 |
|
||||
| Visites confirmées | 45 |
|
||||
| Taux de conversion | 1.8% |
|
||||
| Budget dépensé | 42.50€ |
|
||||
| Coût par visite | 0.94€ |
|
||||
Et un événement "AD_DASHBOARD_VIEWED" est enregistré
|
||||
|
||||
Scénario: A/B testing automatisé des créatives publicitaires
|
||||
Étant donné un annonceur avec 3 versions de publicité
|
||||
Quand le système diffuse les pubs
|
||||
Alors chaque version est diffusée à 33% du trafic
|
||||
Et les performances sont comparées après 1000 impressions
|
||||
Et la meilleure version est automatiquement privilégiée
|
||||
Et un événement "AD_AB_TEST_WINNER_SELECTED" est enregistré
|
||||
|
||||
Scénario: Limite de fréquence stricte pour éviter la saturation
|
||||
Étant donné un utilisateur "charlie@roadwave.fr"
|
||||
Et il a déjà entendu 3 pubs dans la dernière heure
|
||||
Quand le système tente d'insérer une 4ème pub
|
||||
Alors elle est bloquée
|
||||
Et l'utilisateur voit: "Prochaine pub dans 25 min"
|
||||
Et un événement "AD_FREQUENCY_CAP_REACHED" est enregistré
|
||||
|
||||
Scénario: Publicités Premium sponsorisées prioritaires
|
||||
Étant donné un annonceur "Musée du Louvre" avec campagne premium
|
||||
Quand un utilisateur passe à proximité
|
||||
Alors sa publicité est priorisée sur les autres
|
||||
Et elle a un format étendu (45s autorisées)
|
||||
Et un badge "Partenaire officiel" s'affiche
|
||||
Et un événement "AD_PREMIUM_DISPLAYED" est enregistré
|
||||
|
||||
Scénario: Sauvegarde d'offres publicitaires pour utilisation ultérieure
|
||||
Étant donné un utilisateur "david@roadwave.fr" qui entend une pub
|
||||
Quand il clique sur "Sauvegarder l'offre"
|
||||
Alors l'offre est ajoutée à "Mes offres sauvegardées"
|
||||
Et il peut la consulter plus tard
|
||||
Et la validité de l'offre est affichée: "Valable jusqu'au 31/03"
|
||||
Et un événement "AD_OFFER_SAVED" est enregistré
|
||||
|
||||
Scénario: Métriques de performance du système publicitaire
|
||||
Étant donné que 100 000 pubs ont été diffusées
|
||||
Alors les indicateurs suivants sont disponibles:
|
||||
| Métrique | Valeur |
|
||||
| Taux de skip moyen | 62% |
|
||||
| Taux d'écoute complète | 38% |
|
||||
| CTR (Click-Through Rate) | 5.2% |
|
||||
| Taux de conversion (visites) | 3.1% |
|
||||
| Revenu moyen par utilisateur | 2.40€/an |
|
||||
| Satisfaction utilisateurs | 3.8/5 |
|
||||
Et les métriques sont exportées vers le monitoring
|
||||
Reference in New Issue
Block a user