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.
430 lines
13 KiB
Markdown
430 lines
13 KiB
Markdown
2 months ago
|
# 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 :
|
||
|
|
|
||
|
|
1. **Architecture Monolithique** (Application Actuelle)
|
||
|
|
2. **Architecture Microservices** (Choix Retenu)
|
||
|
|
3. **Architecture Serverless** (Alternative Considérée)
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 1. Architecture Monolithique
|
||
|
|
|
||
|
|
### 1.1 Description
|
||
|
|
|
||
|
|
Architecture de l'**application legacy actuelle** BricoLoc.
|
||
|
|
|
||
|
|
```mermaid
|
||
|
|
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.
|
||
|
|
|
||
|
|
```mermaid
|
||
|
|
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).
|
||
|
|
|
||
|
|
```mermaid
|
||
|
|
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 🔧
|
||
|
|
|
||
|
|
1. **Modularité** : Clean Architecture + DDD adapté au domaine métier
|
||
|
|
2. **Scalabilité** : Serverless auto-scale de Vercel
|
||
|
|
3. **Performance** : Edge CDN + Server Components Next.js
|
||
|
|
4. **Maintenabilité** : TypeScript strict, tests, documentation
|
||
|
|
5. **Innovation** : Stack moderne (Next.js 14, React 19, Supabase)
|
||
|
|
|
||
|
|
#### Raisons Métier 💼
|
||
|
|
|
||
|
|
1. **Time to Market** : Développement parallèle par service
|
||
|
|
2. **Coût Optimisé** : Gratuit phase MVP, scale progressif
|
||
|
|
3. **Fiabilité** : Isolation des pannes, retry logic
|
||
|
|
4. **Évolutivité** : Ajout de services facile
|
||
|
|
5. **Recrutement** : Stack attractive (React, TypeScript)
|
||
|
|
|
||
|
|
#### Raisons Pédagogiques 📚
|
||
|
|
|
||
|
|
1. **Apprentissage** : Patterns modernes (Clean Architecture, DDD)
|
||
|
|
2. **Démonstration** : Showcase de compétences architecturales
|
||
|
|
3. **Documentation** : Projet bien documenté
|
||
|
|
4. **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)
|
||
|
|
|
||
|
|
```mermaid
|
||
|
|
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)
|