40 lines
1.5 KiB
Markdown
40 lines
1.5 KiB
Markdown
---
|
|
title: Architecture Monolithique
|
|
created: 2026-06-06
|
|
updated: 2026-06-06
|
|
type: concept
|
|
tags: [tech, architecture]
|
|
confidence: high
|
|
contested: false
|
|
sources: [synthesized]
|
|
---
|
|
# 🗿 Architecture Monolithique
|
|
|
|
## Définition Courte
|
|
Style architectural où toute l'application est construite comme une seule unité déployable, avec une base de code partagée et un processus unique.
|
|
|
|
## Explication Détaillée
|
|
Dans un monolithe, toutes les fonctionnalités (UI, logique métier, accès données) sont compilées et déployées ensemble. Il peut être :
|
|
- **Modulaire** : bien organisé en packages/modules logiques (monolithe "sain").
|
|
- **Big Ball of Mud** : sans structure claire, fortement couplé (anti-pattern).
|
|
|
|
**Avantages** : simplicité de développement au début, debugging facile (un seul processus), transactions ACID triviales, déploiement en un clic.
|
|
**Inconvénients** : scalabilité linéaire (on duplique tout), déploiements risqués, dépendance forte entre équipes, choix technologique verrouillé.
|
|
|
|
## Cas d'Usage
|
|
- MVP et startups en phase de validation (time-to-market).
|
|
- Petites équipes (< 10 devs).
|
|
- Applications avec un domaine métier simple et stable.
|
|
|
|
## Outils Liés
|
|
- **Frameworks** : Django, Rails, Spring Boot, Laravel, NestJS.
|
|
- **Base de données** : PostgreSQL, MySQL.
|
|
|
|
## Pages Liées
|
|
- [[patterns-architecture]]
|
|
- [[architecture-microservices]]
|
|
|
|
## Questions Ouvertes
|
|
- Comment savoir quand il faut extraire un service du monolithe (signaux) ?
|
|
- Un monolithe modulaire est-il un état final acceptable ou une étape transitoire ?
|