Architecture monolithique · Cartes mentales
Architecture monolithique. Une carte mentale modifiable avec des branches colorées, des idées secondaires et des liens. Les courbes montrent les liens; les flèches indiquent les relations où le sens compte.
Un monolithe est une application construite et déployée comme une seule unité : l'interface utilisateur, la logique métier et l'accès aux données s'exécutent tous dans un seul processus sur une base de données partagée, et la mise à l'échelle signifie la réplication de l'ensemble.
Architecture monolithique · Cartes mentales
Le canevas MindMap interactif de cette explication : chaque couloir, ligne et flèche ci-dessus appartient à un véritable diagramme QueryChart que vous pouvez ouvrir et modifier.
Comment lire cette carte mentale
- Commencez par le sujet central, puis suivez une branche colorée pour explorer ses idées.
- Les courbes montrent les liens; les flèches indiquent les relations où le sens compte.
Client request
Cette branche rassemble “Client sends a request”.
One application
Cette branche rassemble “Request enters the single deployable application”, “Business logic module processes it”, “The response returns through the same modules”, “UI module routes and renders”, “Data access module queries the database”.
Shared database
Cette branche rassemble “All modules share a single schema, which keeps joins and transactions simple — the main reason a monolith is so fast to build at first.”.
Scaling tradeoff
Cette branche rassemble “One busy feature forces the entire codebase and database connection pool to be copied to another server — the scaling ceiling that pushes teams toward splitting it.”.
Liens entre les branches
Tous les modules partagent un processus, une base de code et un déploiement : ce confinement est la définition.
La base de données partagée couple chaque module à un seul schéma.
Les demandes transitent par chaque module en un seul aller-retour : il n'y a pas d'appel de service distinct.
La mise à l'échelle est grossière : l'ensemble de l'application est dupliqué, fonctionnalité occupée ou non.
La vitesse de développement du monolithe est réelle ; le plafond d'échelle est ce qu'il échange.
Relations et enseignements clés
- Tous les modules partagent un processus, une base de code et un déploiement : ce confinement est la définition.
- La base de données partagée couple chaque module à un seul schéma.
- Les demandes transitent par chaque module en un seul aller-retour : il n'y a pas d'appel de service distinct.
- La mise à l'échelle est grossière : l'ensemble de l'application est dupliqué, fonctionnalité occupée ou non.
- La vitesse de développement du monolithe est réelle ; le plafond d'échelle est ce qu'il échange.
Quand utiliser ce visuel
- Expliquer pourquoi l'application d'une équipe est difficile à faire évoluer même si elle est facile à développer.
- Enseigner le contraste qui rend les microservices compréhensibles : la scission n'a de sens que face au plafond du monolithe.
- Documenter la structure d'un système existant avant de planifier comment le décomposer.
Comment cela fonctionne
Adapter le sujet central
Renommez le sujet pour votre projet ou votre cours.
Développer les branches
Modifiez les idées et ajoutez des exemples ou des notes.
Relier les idées
Reliez les branches; utilisez une flèche lorsque le sens est important.
Questions fréquentes
Qu'est-ce qu'une architecture monolithique ?
Un monolithe est une application dont l'interface utilisateur, la logique métier et l'accès aux données sont construits, déployés et mis à l'échelle comme une seule unité : une base de code unique produisant un seul artefact déployable, exécuté sur une base de données partagée. Le visuel montre la requête traversant les trois modules dans un seul couloir d'application, car ce confinement est la définition.
Pourquoi les équipes commencent-elles avec un monolithe ?
Parce que pour la plupart des équipes et pendant la majeure partie de la durée de vie d'une application, un monolithe constitue le moyen de livraison le plus rapide. Il n'y a pas de réseau entre les modules, le schéma partagé simplifie les jointures et les transactions, et le déploiement n'est qu'un artefact. L'encadré de base de données partagée du visuel le souligne clairement : l'échange ne devient négatif que lorsque la mise à l'échelle indépendante ou l'autonomie de l'équipe devient la contrainte contraignante.
Quel est le principal problème d’un monolithe ?
Le plafond évolutif et le couplage. La mise à l'échelle signifie la réplication de l'ensemble de l'application, de sorte qu'une fonctionnalité occupée gaspille de la capacité dans tout le reste, et chaque modification touche une base de code et un schéma dont tout le monde dépend. À mesure que l’équipe et la base de code se développent, ces deux effets ralentissent le déploiement et forcent la coordination : les conditions dans lesquelles les équipes commencent à extraire les services.
Comment un monolithe devient-il des microservices ?
Progressivement, en extrayant une capacité à la fois. La première étape consiste à identifier un module qui peut être autonome (ses propres données limitées), puis à lui donner sa propre base de données, une API et éventuellement un déploiement indépendant. L'étape candidate à l'extraction du visuel modélise exactement ceci : marquer le module, couper le couplage et diviser. L’erreur est de réécrire tout le monolithe d’un coup, ce qui explique l’échec des migrations.
Modifier cette carte mentale dans QueryChart
Ouvrez cette carte mentale sur un espace modifiable. Déplacez les idées et ajoutez des branches et des liens.