Files

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

1.8 KiB

Raw Blame History

Documentation des Interfaces

Cette section documente les interfaces utilisateur de RoadWave (mobile et web).

Organisation

Mobile (Flutter)

L'application mobile est l'interface principale pour les utilisateurs finaux (conducteurs, piétons, touristes).

Navigation & Architecture : Structure de navigation, routing
Écran d'accueil : Feed de recommandations géolocalisées
Lecteur audio : Player HLS, contrôles, playlists
Carte & découverte : Vue carte, exploration géographique
Profil & réglages : Jauges d'intérêt, paramètres

Web (Créateurs)

L'interface web est destinée aux créateurs de contenu et aux annonceurs.

Dashboard : Vue d'ensemble, statistiques
Upload de contenu : Import audio, métadonnées, géolocalisation
Statistiques : Analytics, revenus

Conventions de documentation

Captures d'écran

Placez les images dans docs/interfaces/assets/ et référencez-les ainsi :

![Description](assets/mobile/home-screen.png){ width="300" }

Diagrammes de flux

Utilisez Mermaid pour les parcours utilisateur :

graph LR
    A[Ouverture app] --> B{GPS actif?}
    B -->|Oui| C[Chargement recommandations]
    B -->|Non| D[Demande permission]
    D --> C

Onglets multi-plateformes

Pour montrer des variations iOS/Android :

=== "iOS" Comportement spécifique iOS

=== "Android" Comportement spécifique Android

Principes de design

Mobile-first : L'app mobile est l'expérience principale
Géolocalisation centrale : L'UI doit toujours contextualiser par rapport à la position
Audio en arrière-plan : Player persistant, mini-player
Mode sombre : Support obligatoire (conduite de nuit)
Accessibilité : WCAG 2.1 AA minimum

1.8 KiB Raw Blame History