Files

jpgiannetti 852f6d5e16 refactor(docs): réorganiser ADR et règles métier pour clarté

**Changements majeurs** :

1. **Suppression ADR-010 (Commandes volant et likes)** :
   - Contenu consolidé dans Règle 05 (section 5.3)
   - Raison : ADR-010 était du métier déguisé en architecture
   - Section "Implémentation Technique" ajoutée à Règle 05
   - Pattern correct (addition) vs incorrect (multiplication)

2. **Déplacement ADR-011 → Compliance** :
   - `docs/adr/011-conformite-stores.md` → `docs/compliance/stores-submission.md`
   - Raison : Nature opérationnelle/légale, pas architecture technique
   - Nouveau dossier `/docs/compliance/` créé

3. **Renumérotation ADR (010-022)** :
   - Combler les trous de numérotation (010 et 011)
   - ADR-012→010, ADR-013→011, ..., ADR-024→022
   - 22 ADR numérotés en continu (001-022)
   - Historique Git préservé (git mv)

4. **Mise à jour références** :
   - Règle 03 : ADR-010 → Règle 05 (section 5.3)
   - Règle 09 : ADR-010 → Règle 05 (section 5.3)
   - INCONSISTENCIES-ANALYSIS.md : toutes références mises à jour
   - Incohérence #15 annulée (faux problème : modes séparés)

**Résultat** :
- ✅ Séparation claire ADR (technique) vs Règles métier (fonctionnel)
- ✅ Documentation compliance séparée
- ✅ Numérotation ADR continue sans trous
- ✅ Single Source of Truth (pas de redondance)

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

2026-02-01 14:34:12 +01:00

1.9 KiB

Raw Blame History

ADR-010 : Architecture Backend

Statut : Accepté Date : 2025-01-20

Contexte

RoadWave nécessite une architecture backend évolutive tout en gardant la simplicité opérationnelle pour un MVP. Le système doit supporter une croissance progressive de 0 à 10M utilisateurs.

Décision

Monolithe modulaire avec séparation claire en modules internes.

Alternatives considérées

Architecture	Complexité	Coûts infra	Time to market	Évolutivité
Monolithe modulaire	Faible	Faible	Rapide	0-1M users
Microservices	Élevée	Élevée	Lent	1M+ users
Hybrid (Mono + Workers)	Moyenne	Moyenne	Moyen	100K-5M users

Justification

Simplicité : 1 seul binaire Go, déploiement trivial
Transactions : Communications inter-modules en mémoire (pas de latence réseau)
Debugging : Stack traces complètes, profiling unifié
Coûts : 1 serveur suffit pour 100K users (vs N services)
Refactoring : Modules internes bien séparés facilitent migration vers microservices si nécessaire

Structure modulaire

internal/
├── auth/         # Validation JWT, intégration Zitadel
├── user/         # Profils, centres d'intérêt
├── content/      # CRUD contenus, métadonnées
├── geo/          # Recherche géospatiale, algorithme
├── streaming/    # Génération HLS, transcoding
├── moderation/   # Signalements, workflow
├── payment/      # Intégration Mangopay
└── analytics/    # Métriques écoute, jauges

Chaque module suit : handler.go → service.go → repository.go.

Conséquences

Scaling horizontal : réplication complète du binaire (acceptable jusqu'à 1M users)
Transition vers microservices possible en phase 2 (extraction progressive des modules)
Importance de maintenir découplage fort entre modules (interfaces claires)

1.9 KiB Raw Blame History