Files

jpgiannetti 37c62206ad feat(bdd): réorganiser features en catégories api/ui/e2e et créer ADR-024

Résolution des incohérences #10, #11, et #12 de l'analyse d'architecture.

## Phase 1 : Réorganisation Features BDD (Point #10 - RÉSOLU)

- Créer structure features/{api,ui,e2e}
- Déplacer 83 features en 3 catégories via git mv (historique préservé)
  - features/api/ : 53 features (tests API backend)
  - features/ui/ : 22 features (tests UI mobile)
  - features/e2e/ : 8 features (tests end-to-end)

Domaines déplacés :
- API : authentication, recommendation, rgpd-compliance, content-creation,
  moderation, monetisation, premium, radio-live, publicites
- UI : audio-guides, navigation, interest-gauges, mode-offline,
  partage, profil, recherche
- E2E : abonnements, error-handling

## Phase 2 : Mise à jour Documentation

### ADR-007 - Tests BDD
- Ajouter section "Convention de Catégorisation des Features"
- Documenter règles api/ui/e2e avec exemples concrets
- Spécifier step definitions (backend Go, mobile Dart)

### ADR-024 - Stratégie CI/CD Monorepo (NOUVEAU)
- Créer ADR dédié pour stratégie CI/CD avec path filters
- Architecture workflows séparés (backend.yml, mobile.yml, shared.yml)
- Configuration path filters détaillée avec exemples YAML
- Matrice de déclenchement et optimisations (~70% gain temps CI)
- Plan d'implémentation (~2h, reporté jusqu'au développement)

### ADR-016 - Organisation Monorepo
- Simplifier en retirant section CI/CD détaillée
- Ajouter référence vers ADR-024 pour stratégie CI/CD

### INCONSISTENCIES-ANALYSIS.md
- Point #10 (Tests BDD synchronisés) : ✅ RÉSOLU
  - Catégorisation features implémentée
  - ADR-007 mis à jour avec convention complète
- Point #11 (70/30 Split paiements) : ✅ ANNULÉ (faux problème)
  - ADR-009 et Règle 18 parfaitement cohérents
  - Documentation exhaustive existante (formule, SQL, comparaisons)
- Point #12 (Monorepo path filters) : ⏸️ DOCUMENTÉ
  - Architecture CI/CD complète dans ADR-024
  - Implémentation reportée (projet en phase documentation)
- Métriques mises à jour :
  - MODERATE : 6/9 traités (4 résolus + 1 annulé + 1 documenté)
  - ADR à jour : 100% (19/19 avec ADR-024)

## Phase 3 : Validation

- Structure features validée (api/ui/e2e, aucun répertoire restant)
- Historique Git préservé (git mv, renommages détectés)
- 83 features total (API: 53, UI: 22, E2E: 8)

Closes: Point #10 (résolu), Point #11 (annulé), Point #12 (documenté)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

2026-02-01 11:31:41 +01:00

3.7 KiB

Raw Blame History

ADR-016 : Organisation en Monorepo

Statut : Accepté Date : 2025-01-24

Contexte

RoadWave comprend plusieurs composants (backend Go, mobile React Native/Flutter, documentation, tests BDD). Il faut décider de l'organisation des repositories : monorepo unique, multirepo avec submodules, ou repos totalement séparés.

Les tests Gherkin existants décrivent des fonctionnalités bout-en-bout (front + mobile + back) et doivent rester cohérents entre tous les composants.

Décision

Monorepo unique contenant backend, mobile, documentation et features Gherkin.

Alternatives considérées

Option	Cohérence	Complexité	Onboarding	Déploiements
Monorepo	Excellente	Faible	Simple (1 clone)	Couplés
Multirepo + submodules	Moyenne	Élevée	Complexe	Indépendants
Multirepo séparés	Faible	Moyenne	Moyen	Indépendants

Justification

Source de vérité unique : documentation et Gherkin partagés, pas de désynchronisation
Versionning cohérent : un tag Git = release complète front + back compatible
Tests e2e simplifiés : tout le code disponible localement pour tests intégrés
Expérience développeur : un seul git clone, historique unifié, changements cross-stack facilités
Stade du projet : début de projet où agilité et changements rapides sont critiques

Structure

roadwave/
├── docs/                          # Documentation commune (ADR, règles métier)
├── features/                      # Tests BDD Gherkin partagés
│   ├── authentication/
│   ├── navigation/
│   └── ...
├── backend/                       # Application Go
│   ├── cmd/
│   ├── internal/
│   ├── pkg/
│   ├── migrations/
│   ├── tests/
│   │   └── bdd/                   # Step definitions Go (API)
│   └── go.mod
├── mobile/                        # Application React Native/Flutter
│   ├── src/
│   ├── tests/
│   │   └── bdd/                   # Step definitions mobile (UI)
│   └── package.json / pubspec.yaml
├── shared/                        # Code partagé (types, contrats API)
├── docker-compose.yml             # Stack complète locale
└── Makefile                       # Commandes communes

Gestion des tests Gherkin

Principe : Les fichiers .feature restent partagés dans /features, mais chaque projet implémente ses step definitions.

features/authentication/inscription.feature    → Scénario fonctionnel

backend/tests/bdd/inscription_steps.go         → Teste l'API
mobile/tests/bdd/inscription_steps.dart        → Teste l'UI mobile

Cela garantit que :

Les spécifications métier sont uniques et cohérentes
Chaque couche teste sa responsabilité
Les tests valident le contrat entre front et back

Outillage

Turborepo ou Nx : orchestration des builds/tests, cache intelligent
Docker Compose : environnement de dev local (PostgreSQL, Redis, backend, etc.)
Make : commandes communes (make test, make build, make dev)
CI/CD : GitHub Actions avec path filters (voir ADR-024)

Conséquences

Positif : cohérence maximale, onboarding simplifié, changements cross-stack facilités
Négatif : repo plus volumineux, nécessite CI intelligente pour éviter builds lents
Migration future : si le monorepo devient ingérable (>100k LOC), split possible mais improbable à moyen terme
Permissions : tout le monde voit tout (transparence encouragée en phase startup)

3.7 KiB Raw Blame History