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,242 @@
|
||||
# language: fr
|
||||
Fonctionnalité: Gestion des contenus supprimés pendant offline
|
||||
En tant qu'utilisateur offline
|
||||
Je veux être informé des contenus supprimés à la reconnexion
|
||||
Afin de comprendre pourquoi certains contenus ont disparu
|
||||
|
||||
Contexte:
|
||||
Étant donné qu'un utilisateur a téléchargé 50 contenus offline
|
||||
Et que l'utilisateur part offline pendant 7 jours
|
||||
|
||||
# Processus de synchronisation
|
||||
|
||||
Scénario: Reconnexion WiFi - Validation des contenus locaux
|
||||
Étant donné que l'utilisateur se reconnecte au WiFi
|
||||
Quand l'application détecte la connexion internet
|
||||
Alors une requête API est envoyée: GET /offline/validate
|
||||
Et l'API retourne:
|
||||
"""json
|
||||
{
|
||||
"valid_ids": [1, 2, 3, 5, 7, 8, ...],
|
||||
"deleted_ids": [4, 6, 10],
|
||||
"metadata_updates": [
|
||||
{"id": 9, "new_title": "Nouveau titre", "creator": "CreateurA"}
|
||||
]
|
||||
}
|
||||
"""
|
||||
|
||||
Scénario: Traitement réponse validation - Suppression fichiers locaux
|
||||
Étant donné que l'API retourne deleted_ids = [4, 6, 10]
|
||||
Quand l'application traite la réponse
|
||||
Alors les fichiers locaux des contenus 4, 6, 10 sont supprimés immédiatement
|
||||
Et les métadonnées locales SQLite sont mises à jour
|
||||
Et un compteur de suppressions est incrémenté
|
||||
|
||||
Scénario: Renouvellement validité contenus valides
|
||||
Étant donné que l'API retourne valid_ids = [1, 2, 3, 5, 7, 8, ...]
|
||||
Quand l'application traite la réponse
|
||||
Alors la validité de ces contenus est renouvelée pour 30 jours
|
||||
Et la date d'expiration est mise à jour: today + 30 jours
|
||||
|
||||
Scénario: Mise à jour métadonnées modifiées
|
||||
Étant donné que l'API retourne metadata_updates avec un nouveau titre
|
||||
Quand l'application traite la réponse
|
||||
Alors la base SQLite locale est mise à jour:
|
||||
| content_id | nouveau_titre | nouveau_creator |
|
||||
| 9 | Nouveau titre | CreateurA |
|
||||
Et les fichiers audio restent inchangés
|
||||
|
||||
# Gestion contenu en cours d'écoute
|
||||
|
||||
Scénario: Contenu supprimé en cours de lecture - Arrêt immédiat
|
||||
Étant donné que l'utilisateur écoute le contenu 4 (à 1:30 sur 3:00)
|
||||
Et que l'API retourne deleted_ids = [4]
|
||||
Quand la synchronisation détecte que contenu 4 est supprimé
|
||||
Alors la lecture s'arrête immédiatement
|
||||
Et une modal s'affiche:
|
||||
"""
|
||||
Contenu supprimé
|
||||
|
||||
Ce contenu n'est plus disponible
|
||||
et a été retiré par le créateur.
|
||||
|
||||
Passage au contenu suivant...
|
||||
|
||||
[OK]
|
||||
"""
|
||||
Et le fichier audio est supprimé localement
|
||||
Et après 2 secondes, le contenu suivant démarre
|
||||
|
||||
Scénario: Contenu supprimé PAS en cours - Suppression silencieuse
|
||||
Étant donné que l'utilisateur écoute le contenu 1
|
||||
Et que l'API retourne deleted_ids = [4, 6, 10]
|
||||
Quand la synchronisation traite les suppressions
|
||||
Alors les fichiers 4, 6, 10 sont supprimés silencieusement
|
||||
Et aucune interruption de lecture ne se produit
|
||||
Et un toast récapitulatif est affiché à la fin de la lecture actuelle
|
||||
|
||||
# Message récapitulatif
|
||||
|
||||
Scénario: Plusieurs contenus supprimés - Popup récapitulative
|
||||
Étant donné que 3 contenus ont été supprimés (4, 6, 10)
|
||||
Quand la synchronisation est terminée
|
||||
Alors une popup s'affiche:
|
||||
"""
|
||||
Contenus supprimés
|
||||
|
||||
3 contenus téléchargés ne sont plus
|
||||
disponibles et ont été retirés.
|
||||
|
||||
Les créateurs peuvent supprimer ou
|
||||
modifier leurs contenus à tout moment.
|
||||
|
||||
[Voir la liste] [OK]
|
||||
"""
|
||||
|
||||
Scénario: Bouton "Voir la liste" - Affichage détails
|
||||
Étant donné que la popup récapitulative est affichée
|
||||
Quand l'utilisateur clique sur [Voir la liste]
|
||||
Alors une nouvelle vue s'affiche avec:
|
||||
| Contenu | Créateur | Raison |
|
||||
| Podcast Auto Episode 4| CreateurA | Retiré créateur |
|
||||
| Musique Classique | CreateurB | Modération |
|
||||
| Audio-guide Paris | CreateurC | Retiré créateur |
|
||||
Et l'historique est conservé 7 jours puis purgé
|
||||
|
||||
Scénario: Bouton "OK" - Fermeture popup
|
||||
Étant donné que la popup récapitulative est affichée
|
||||
Quand l'utilisateur clique sur [OK]
|
||||
Alors la popup se ferme
|
||||
Et l'utilisateur continue normalement
|
||||
Et l'historique des suppressions reste accessible pendant 7 jours
|
||||
|
||||
# Toast notification
|
||||
|
||||
Scénario: Toast simple si 1 seul contenu supprimé
|
||||
Étant donné qu'un seul contenu a été supprimé (4)
|
||||
Quand la synchronisation est terminée
|
||||
Alors un toast s'affiche pendant 5 secondes:
|
||||
"""
|
||||
1 contenu supprimé a été retiré
|
||||
"""
|
||||
Et aucune popup n'est affichée (toast suffit)
|
||||
|
||||
Scénario: Popup si 2+ contenus supprimés
|
||||
Étant donné que 2 ou plus contenus ont été supprimés
|
||||
Quand la synchronisation est terminée
|
||||
Alors une popup complète est affichée (pas juste un toast)
|
||||
Car l'utilisateur doit être informé clairement
|
||||
|
||||
# Motifs de suppression
|
||||
|
||||
Scénario: Contenu supprimé par créateur volontairement
|
||||
Étant donné que le créateur a supprimé le contenu 4 volontairement
|
||||
Quand l'API retourne deleted_ids = [4] avec motif "creator_deleted"
|
||||
Alors le contenu est retiré immédiatement (pas de grace period MVP)
|
||||
Et la raison affichée est: "Retiré par le créateur"
|
||||
|
||||
Scénario: Contenu supprimé par modération (violation CGU)
|
||||
Étant donné que le contenu 6 a été modéré pour violation CGU
|
||||
Quand l'API retourne deleted_ids = [6] avec motif "moderation"
|
||||
Alors le contenu est retiré immédiatement
|
||||
Et la raison affichée est: "Retiré pour modération"
|
||||
|
||||
Scénario: Contenu passé en Premium (créateur change statut)
|
||||
Étant donné que le contenu 10 est passé en "Premium exclusif"
|
||||
Et que l'utilisateur est gratuit
|
||||
Quand l'API retourne deleted_ids = [10] avec motif "premium_only"
|
||||
Alors le contenu est retiré immédiatement
|
||||
Et la raison affichée est: "Réservé aux abonnés Premium"
|
||||
|
||||
# Justification KISS
|
||||
|
||||
Scénario: Comparaison avec grace period - Simplicité MVP
|
||||
Étant donné qu'on compare la suppression immédiate vs grace period
|
||||
Quand on évalue les avantages KISS
|
||||
Alors les avantages suppression immédiate sont:
|
||||
| avantage | description |
|
||||
| Simplicité technique | Pas de gestion états intermédiaires complexes |
|
||||
| Respect créateur | Volonté immédiate respectée |
|
||||
| Conformité légale | Contenu illégal retiré immédiatement |
|
||||
| Cas rare | Peu de créateurs suppriment contenus après publi |
|
||||
|
||||
# Post-MVP : Grace period (si feedback négatifs)
|
||||
|
||||
Scénario: Post-MVP - Grace period 7 jours pour suppression créateur volontaire
|
||||
Étant donné qu'on implémente la grace period post-MVP
|
||||
Et que le contenu 4 est supprimé volontairement par le créateur
|
||||
Quand l'API retourne deleted_ids = [4] avec motif "creator_deleted"
|
||||
Alors le contenu est marqué "Bientôt retiré" avec badge
|
||||
Et l'utilisateur peut encore l'écouter pendant 7 jours
|
||||
Et après 7 jours, le contenu est supprimé
|
||||
|
||||
Scénario: Post-MVP - Pas de grace period pour modération
|
||||
Étant donné qu'on implémente la grace period post-MVP
|
||||
Et que le contenu 6 est modéré (illégal, violation CGU)
|
||||
Quand l'API retourne deleted_ids = [6] avec motif "moderation"
|
||||
Alors le contenu est supprimé immédiatement (pas de grace period)
|
||||
Car sécurité/légalité prime
|
||||
|
||||
Scénario: Post-MVP - Grace period si user Premium et contenu devient Premium
|
||||
Étant donné qu'on implémente la grace period post-MVP
|
||||
Et que le contenu 10 passe en "Premium exclusif"
|
||||
Et que l'utilisateur a un abonnement Premium
|
||||
Quand l'API retourne deleted_ids = [10] avec motif "premium_only"
|
||||
Alors l'utilisateur Premium conserve l'accès (pas supprimé)
|
||||
Mais l'utilisateur gratuit perd l'accès après 7 jours
|
||||
|
||||
# Cas limites
|
||||
|
||||
Scénario: Tous les contenus offline supprimés - Message spécifique
|
||||
Étant donné que l'utilisateur avait 5 contenus offline
|
||||
Et que les 5 contenus ont été supprimés pendant offline
|
||||
Quand la synchronisation retourne deleted_ids = [1, 2, 3, 4, 5]
|
||||
Alors une popup spécifique s'affiche:
|
||||
"""
|
||||
Tous vos contenus offline ont été supprimés
|
||||
|
||||
Les 5 contenus téléchargés ne sont plus disponibles.
|
||||
|
||||
Téléchargez de nouveaux contenus pour écouter offline.
|
||||
|
||||
[Parcourir contenus] [OK]
|
||||
"""
|
||||
|
||||
Scénario: Contenu supprimé puis utilisateur re-télécharge
|
||||
Étant donné que le contenu 4 a été supprimé pendant offline
|
||||
Et que l'utilisateur a vu la notification
|
||||
Quand l'utilisateur se reconnecte et browse les contenus
|
||||
Alors le contenu 4 n'apparaît plus dans la liste
|
||||
Et l'utilisateur ne peut pas le re-télécharger (supprimé définitivement)
|
||||
|
||||
Scénario: Historique suppressions conservé 7 jours
|
||||
Étant donné que 3 contenus ont été supprimés le 1er février
|
||||
Quand l'utilisateur consulte l'historique des suppressions le 7 février
|
||||
Alors l'historique est toujours visible
|
||||
Quand l'utilisateur consulte l'historique le 9 février (7+ jours)
|
||||
Alors l'historique a été purgé automatiquement
|
||||
|
||||
# Statistiques côté API
|
||||
|
||||
Scénario: API - Comptabilisation contenus supprimés pendant offline
|
||||
Étant donné que 1000 utilisateurs étaient offline pendant 7 jours
|
||||
Et que 150 contenus ont été supprimés pendant cette période
|
||||
Quand l'API génère les métriques de synchronisation
|
||||
Alors les statistiques affichent:
|
||||
| métrique | valeur |
|
||||
| Utilisateurs reconnectés | 1000 |
|
||||
| Contenus supprimés détectés | 4500 |
|
||||
| Moyenne contenus supprimés/user | 4.5 |
|
||||
| Users affectés (≥1 suppression) | 850 |
|
||||
|
||||
# Performance
|
||||
|
||||
Scénario: Requête GET /offline/validate - Performance optimisée
|
||||
Étant donné qu'un utilisateur a 50 contenus offline
|
||||
Quand l'API reçoit GET /offline/validate avec la liste des 50 IDs
|
||||
Alors la requête SQL vérifie l'existence des contenus en batch:
|
||||
"""sql
|
||||
SELECT id FROM contents WHERE id IN (1,2,3,...,50) AND deleted_at IS NULL
|
||||
"""
|
||||
Et la réponse est générée en <200ms
|
||||
Et Redis cache les résultats pour éviter requêtes répétées
|
||||
Reference in New Issue
Block a user