852f6d5e16
**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>
51 lines
1.9 KiB
Markdown
51 lines
1.9 KiB
Markdown
# 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)
|