Files
roadwave/docs/domains/moderation/features/api/limite-temporelle-anti-abus.feature
jpgiannetti 5e5fcf4714 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.
2026-02-07 17:15:02 +01:00

52 lines
2.3 KiB
Gherkin

# language: fr
@api @moderation @anti-abuse @mvp
Fonctionnalité: Limites temporelles anti-abus de modération
En tant que plateforme
Je veux limiter les signalements abusifs
Afin de prévenir le spam et les abus du système
Scénario: Limitation à 20 signalements par jour
Étant donné un utilisateur "alice@roadwave.fr" qui a fait 20 signalements aujourd'hui
Quand il tente un 21ème signalement
Alors le signalement est bloqué
Et un message s'affiche: "Limite quotidienne atteinte (20 signalements). Réessayez demain."
Et un événement "REPORT_DAILY_LIMIT_REACHED" est enregistré
Scénario: Limite augmentée pour utilisateurs de confiance
Étant donné un utilisateur de confiance
Alors sa limite quotidienne est de 50 signalements
Et un événement "TRUSTED_USER_HIGHER_LIMIT" est enregistré
Scénario: Cooldown de 5 minutes entre signalements
Étant donné un utilisateur qui vient de faire un signalement
Quand il tente un nouveau signalement 2 minutes après
Alors le signalement est bloqué
Et un message affiche: "Attendez 3 minutes avant le prochain signalement"
Et un événement "REPORT_COOLDOWN_ACTIVE" est enregistré
Scénario: Détection de signalements en masse suspects
Étant donné un utilisateur qui fait 10 signalements en 10 minutes
Quand le système détecte le pattern
Alors une alerte modérateur est déclenchée
Et l'utilisateur passe en review manuelle
Et un événement "MASS_REPORTING_DETECTED" est enregistré
Scénario: Blocage temporaire pour abus répétés
Étant donné un utilisateur avec 10 signalements rejetés en 24h
Quand le 10ème est rejeté
Alors l'utilisateur est bloqué de la modération pour 7 jours
Et un message explique: "Trop de signalements invalides. Blocage temporaire."
Et un événement "REPORTING_SUSPENDED_ABUSE" est enregistré
Scénario: Métriques de détection d'abus
Étant donné que 1000 utilisateurs ont tenté d'abuser
Alors les indicateurs suivants sont disponibles:
| Métrique | Valeur |
| Tentatives de spam détectées | 1,234 |
| Utilisateurs bloqués | 156 |
| Faux positifs | 2% |
| Taux de récidive après blocage | 15% |
Et les métriques sont exportées vers le monitoring