37c62206ad
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>
88 lines
3.7 KiB
Markdown
88 lines
3.7 KiB
Markdown
# 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](024-strategie-cicd-monorepo.md))
|
|
|
|
## 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)
|