You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

13 KiB

Raw Blame History

Comparaison des Styles Architecturaux - BricoLoc

Version : 1.0
Date : 31 Octobre 2025
Projet : BricoLoc - Migration Architecturale

Contexte

Ce document compare les 3 styles architecturaux évalués pour le projet BricoLoc :

Architecture Monolithique (Application Actuelle)
Architecture Microservices (Choix Retenu)
Architecture Serverless (Alternative Considérée)

1. Architecture Monolithique

1.1 Description

Architecture de l'application legacy actuelle BricoLoc.

graph TB
    subgraph "Monolithic Application"
        UI[UI Layer<br/>EJS Templates]
        Business[Business Logic Layer<br/>Routes + Controllers]
        Data[Data Access Layer<br/>SQLite]
    end
    
    Client --> UI
    UI --> Business
    Business --> Data
    Data --> DB[(SQLite DB)]

1.2 Caractéristiques

Structure :

Tout le code dans un seul projet
Base de données SQLite unique
Déploiement en un seul bloc
Couplage fort entre composants

Technologies :

Backend : Node.js + Express
Frontend : EJS Templates (server-side rendering)
Database : SQLite
Deployment : VM unique

1.3 Avantages ✅

Avantage	Description	Impact
Simplicité	Structure simple à comprendre	⭐⭐⭐⭐⭐
Performance	Pas de latence réseau entre composants	⭐⭐⭐⭐
Transactions	ACID natif sur toute la base	⭐⭐⭐⭐⭐
Déploiement Simple	Un seul artefact à déployer	⭐⭐⭐⭐
Debugging	Debugging simple (single process)	⭐⭐⭐⭐⭐
Coût	Infrastructure minimale	⭐⭐⭐⭐⭐

1.4 Inconvénients ❌

Inconvénient	Description	Impact
Scalabilité	Impossible de scaler par fonctionnalité	⭐⭐⭐⭐⭐
Maintenabilité	Code spaghetti, couplage fort	⭐⭐⭐⭐⭐
Technologie	Bloqué sur SQLite, stack monolithique	⭐⭐⭐⭐
Déploiement	Redéploiement complet pour chaque changement	⭐⭐⭐⭐
Résilience	Single point of failure	⭐⭐⭐⭐⭐
Innovation	Difficile d'adopter de nouvelles technos	⭐⭐⭐⭐

1.5 Évaluation Globale

Critère	Note	Commentaire
Maintenabilité	2/10	Code legacy difficile à maintenir
Scalabilité	2/10	Scalabilité verticale uniquement
Performance	6/10	Correcte pour petit trafic
Fiabilité	3/10	SPOF, pas de redondance
Sécurité	4/10	Vulnérabilités connues (SQL injection)
Coût	9/10	Infrastructure minimale
Time to Market	3/10	Modifications longues et risquées

Score Total : 29/70 (41%)

2. Architecture Microservices (Choix Retenu) ✨

2.1 Description

Architecture moderne hybride avec 6 microservices autonomes.

graph TB
    subgraph "Frontend"
        NextJS[Next.js 14<br/>App Router]
    end
    
    subgraph "Microservices"
        Auth[Auth Service]
        Catalogue[Catalogue Service]
        Reservation[Reservation Service]
        Inventory[Inventory Service]
        Payment[Payment Service]
        Notification[Notification Service]
    end
    
    subgraph "Infrastructure"
        Supabase[(Supabase<br/>PostgreSQL)]
        Storage[Supabase Storage]
        Realtime[Realtime]
    end
    
    NextJS --> Auth
    NextJS --> Catalogue
    NextJS --> Reservation
    NextJS --> Inventory
    NextJS --> Payment
    NextJS --> Notification
    
    Auth --> Supabase
    Catalogue --> Supabase
    Reservation --> Supabase
    Inventory --> Supabase
    Payment --> Supabase
    Notification --> Supabase
    
    Catalogue --> Storage
    Notification --> Realtime

2.2 Caractéristiques

Structure :

6 services autonomes avec bounded contexts
Clean Architecture (3 couches) par service
Base de données partagée (Supabase PostgreSQL)
Communication REST + Event Bus

Technologies :

Frontend : Next.js 14, React 18, TypeScript
Backend : Next.js API Routes (serverless)
Database : Supabase (PostgreSQL)
Auth : Supabase Auth
Deployment : Vercel Edge Network

2.3 Avantages ✅

Avantage	Description	Impact
Modularité	Services autonomes, bounded contexts clairs	⭐⭐⭐⭐⭐
Scalabilité	Scale indépendamment par service	⭐⭐⭐⭐⭐
Maintenabilité	Code organisé, Clean Architecture	⭐⭐⭐⭐⭐
Résilience	Isolation des pannes	⭐⭐⭐⭐
Innovation	Stack moderne (Next.js 14, React 19)	⭐⭐⭐⭐⭐
Team Autonomy	Équipes peuvent travailler indépendamment	⭐⭐⭐⭐
Testabilité	Tests isolés par service	⭐⭐⭐⭐⭐
Performance	Serverless auto-scale, CDN edge	⭐⭐⭐⭐⭐

2.4 Inconvénients ❌

Inconvénient	Description	Impact
Complexité	Plus de services à gérer	⭐⭐⭐
Latence	Calls inter-services (REST)	⭐⭐
Transactions	Transactions distribuées complexes	⭐⭐⭐
Debugging	Debugging distribué plus complexe	⭐⭐⭐
Coût	Infrastructure plus coûteuse	⭐⭐

2.5 Évaluation Globale

Critère	Note	Commentaire
Maintenabilité	9/10	Clean Architecture, TypeScript strict
Scalabilité	10/10	Serverless auto-scale illimité
Performance	9/10	Edge CDN, optimisations Next.js
Fiabilité	8/10	Isolation des pannes, retry logic
Sécurité	9/10	RLS, JWT, HTTPS, CSP
Coût	7/10	Gratuit phase MVP, scale avec usage
Time to Market	8/10	Développement parallèle possible

Score Total : 60/70 (86%) ✨

3. Architecture Serverless Pure

3.1 Description

Architecture 100% serverless avec FaaS (Functions as a Service).

graph TB
    subgraph "Frontend"
        StaticSite[Static Site<br/>React SPA]
    end
    
    subgraph "Backend Functions"
        F1[Auth Function]
        F2[Catalogue Function]
        F3[Reservation Function]
        F4[Inventory Function]
        F5[Payment Function]
        F6[Notification Function]
    end
    
    subgraph "Services"
        API[API Gateway]
        DB[(Managed DB)]
        Queue[Message Queue]
        Storage[Object Storage]
    end
    
    StaticSite --> API
    API --> F1
    API --> F2
    API --> F3
    API --> F4
    API --> F5
    API --> F6
    
    F1 --> DB
    F2 --> DB
    F3 --> Queue
    F4 --> Storage

3.2 Caractéristiques

Structure :

Frontend statique (React SPA)
Backend = collection de fonctions indépendantes
Pas de serveur à gérer
Event-driven architecture

Technologies Possibles :

Frontend : React SPA, Vite
Backend : AWS Lambda / Google Cloud Functions
Database : DynamoDB / Firestore
Auth : Auth0 / Firebase Auth
Deployment : AWS / GCP / Azure

3.3 Avantages ✅

Avantage	Description	Impact
Scalabilité Extrême	Scale automatique illimité	⭐⭐⭐⭐⭐
Pay-per-Use	Coût proportionnel à l'usage	⭐⭐⭐⭐⭐
Zero Ops	Pas de serveur à maintenir	⭐⭐⭐⭐⭐
Resilience	Redondance native cloud provider	⭐⭐⭐⭐⭐
Global Deployment	Multi-région par défaut	⭐⭐⭐⭐⭐

3.4 Inconvénients ❌

Inconvénient	Description	Impact
Cold Start	Latence au démarrage des fonctions	⭐⭐⭐⭐
Vendor Lock-in	Dépendance forte au cloud provider	⭐⭐⭐⭐⭐
Debugging	Debugging très complexe	⭐⭐⭐⭐⭐
Stateless	Pas de state partagé	⭐⭐⭐
Coût Imprévisible	Coûts peuvent exploser avec le trafic	⭐⭐⭐⭐
Complexité	Orchestration complexe	⭐⭐⭐⭐⭐
Testing	Tests locaux difficiles	⭐⭐⭐⭐

3.5 Évaluation Globale

Critère	Note	Commentaire
Maintenabilité	6/10	Complexité distribuée élevée
Scalabilité	10/10	Scalabilité illimitée
Performance	7/10	Excellent sauf cold starts
Fiabilité	9/10	Redondance native
Sécurité	8/10	Sécurité gérée par provider
Coût	6/10	Imprévisible à grande échelle
Time to Market	5/10	Complexité freine le développement

Score Total : 51/70 (73%)

4. Comparaison Détaillée

4.1 Tableau Comparatif

Critère	Monolithique	Microservices ✨	Serverless
Complexité initiale	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Scalabilité	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Performance	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
Maintenabilité	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
Testabilité	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
Déploiement	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Coût (MVP)	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
Coût (Scale)	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
Résilience	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Innovation	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
Learning Curve	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Debugging	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐

4.2 Cas d'Usage Idéaux

Monolithique

✅ Petite application
✅ Équipe réduite
✅ Budget limité
✅ Trafic prévisible
❌ BricoLoc (legacy, non maintainable)

Microservices ✨

✅ Application moyenne à grande
✅ Équipes multiples
✅ Besoin de scalabilité
✅ Évolution rapide
✅ BricoLoc - CHOIX OPTIMAL

Serverless

✅ Trafic très variable (spikes)
✅ Event-driven workflows
✅ Budget pay-per-use strict
✅ Pas d'expertise DevOps
❌ BricoLoc (trop complexe pour le projet)

5. Décision et Justification

5.1 Choix Retenu : Architecture Microservices Hybride ✨

5.2 Raisons du Choix

Raisons Techniques 🔧

Modularité : Clean Architecture + DDD adapté au domaine métier
Scalabilité : Serverless auto-scale de Vercel
Performance : Edge CDN + Server Components Next.js
Maintenabilité : TypeScript strict, tests, documentation
Innovation : Stack moderne (Next.js 14, React 19, Supabase)

Raisons Métier 💼

Time to Market : Développement parallèle par service
Coût Optimisé : Gratuit phase MVP, scale progressif
Fiabilité : Isolation des pannes, retry logic
Évolutivité : Ajout de services facile
Recrutement : Stack attractive (React, TypeScript)

Raisons Pédagogiques 📚

Apprentissage : Patterns modernes (Clean Architecture, DDD)
Démonstration : Showcase de compétences architecturales
Documentation : Projet bien documenté
Migration : Démontre migration Monolith → Microservices

5.3 Pourquoi Pas Serverless Pur ?

Raison	Explication
Complexité	Trop complexe pour un projet pédagogique
Vendor Lock-in	Dépendance forte AWS/GCP non souhaitée
Debugging	Debugging distribué très difficile
Learning Curve	Courbe d'apprentissage trop raide
Overkill	Pas besoin de cette échelle pour BricoLoc

5.4 Compromis Choisi

Architecture Microservices avec Infrastructure Serverless :

Bénéfices des microservices (modularité, maintenabilité)
Bénéfices du serverless (auto-scale, zero-ops)
Évite les inconvénients du serverless pur (lock-in, complexité)

6. Migration Path

6.1 Étapes de Migration (Monolith → Microservices)

graph LR
    M[Monolith] -->|Semaine 5-6| Auth[Auth Service]
    M -->|Semaine 7| Cat[Catalogue Service]
    M -->|Semaine 8| Res[Reservation Service]
    M -->|Semaine 9| Inv[Inventory Service]
    M -->|Semaine 10| Pay[Payment Service]
    M -->|Semaine 10| Not[Notification Service]

6.2 Stratégie : Strangler Fig Pattern

Remplacement progressif du monolithe par les microservices.

Phase 1 : Nouveau frontend + Auth Service
Phase 2 : Migration domaine par domaine
Phase 3 : Décommission du monolithe

7. Risques et Mitigation

7.1 Risques Identifiés

Risque	Probabilité	Impact	Mitigation
Complexité accrue	Haute	Moyen	Documentation, formation
Latence réseau	Moyenne	Faible	Cache, CDN edge
Transactions distribuées	Haute	Moyen	Saga pattern, idempotence
Debugging difficile	Moyenne	Moyen	Logging structuré, tracing
Coûts imprévus	Faible	Moyen	Monitoring, alertes budget

Conclusion

L'Architecture Microservices Hybride est le choix optimal pour BricoLoc Moderne car elle offre :

✅ Maintenabilité et évolutivité maximales
✅ Stack moderne et attractive
✅ Scalabilité serverless sans complexité pure FaaS
✅ Coût maîtrisé (gratuit en MVP)
✅ Projet pédagogique démonstratif

Score Final : 60/70 (86%) vs Monolithe 29/70 (41%)

Prochaine révision : Semaine 10 (après première release)

13 KiB Raw Blame History

Comparaison des Styles Architecturaux - BricoLoc

Contexte

1. Architecture Monolithique

1.1 Description

1.2 Caractéristiques

1.3 Avantages ✅

1.4 Inconvénients ❌

1.5 Évaluation Globale

2. Architecture Microservices (Choix Retenu) ✨

2.1 Description

2.2 Caractéristiques

2.3 Avantages ✅

2.4 Inconvénients ❌

2.5 Évaluation Globale

3. Architecture Serverless Pure

3.1 Description

3.2 Caractéristiques

3.3 Avantages ✅

3.4 Inconvénients ❌

3.5 Évaluation Globale

4. Comparaison Détaillée

4.1 Tableau Comparatif

4.2 Cas d'Usage Idéaux

Monolithique

Microservices ✨

Serverless

5. Décision et Justification

5.1 Choix Retenu : Architecture Microservices Hybride ✨

5.2 Raisons du Choix

Raisons Techniques 🔧

Raisons Métier 💼

Raisons Pédagogiques 📚

5.3 Pourquoi Pas Serverless Pur ?

5.4 Compromis Choisi

6. Migration Path

6.1 Étapes de Migration (Monolith → Microservices)

6.2 Stratégie : Strangler Fig Pattern

7. Risques et Mitigation

7.1 Risques Identifiés

Conclusion

13 KiB

Raw Blame History