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 (rebuild seulement ce qui change)

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