Monolithe

Un monolithe est une architecture logicielle traditionnelle où l'ensemble du code d'une application (interface utilisateur, logique métier, accès aux données) est regroupé dans un seul projet déployé comme une unité cohésive. Contrairement aux architectures distribuées, toutes les fonctionnalités partagent le même processus, la même base de code et le même espace mémoire.

Fondements

• Base de code unique regroupant toutes les couches applicatives (présentation, métier, données)
• Déploiement atomique : l'application entière est déployée d'un bloc
• Couplage fort entre les modules au sein d'un même processus
• Communication intra-processus via appels de méthodes directs plutôt que par réseau

Avantages

• Simplicité de développement : un seul projet, une seule technologie, débogage simplifié
• Performance optimale grâce aux appels de méthodes directs sans latence réseau
• Transactions ACID facilitées : gestion cohérente des données dans une seule base
• Déploiement simple : un seul artefact à gérer et versionner
• Courbe d'apprentissage réduite pour les nouvelles recrues
• Moins de complexité opérationnelle : un seul serveur à monitorer initialement

Exemple concret

Voici une structure typique d'application monolithique e-commerce avec Spring Boot :

// Structure d'un monolithe e-commerce
project-root/
├── src/
│   ├── controllers/      // Couche présentation
│   │   ├── ProductController.ts
│   │   ├── OrderController.ts
│   │   └── UserController.ts
│   ├── services/         // Logique métier
│   │   ├── ProductService.ts
│   │   ├── OrderService.ts
│   │   ├── PaymentService.ts
│   │   └── InventoryService.ts
│   ├── repositories/     // Accès données
│   │   ├── ProductRepository.ts
│   │   └── OrderRepository.ts
│   ├── models/
│   │   ├── Product.ts
│   │   └── Order.ts
│   └── app.ts           // Point d'entrée unique
├── database/
│   └── migrations/
└── package.json

// Exemple d'appel interne direct
class OrderController {
  constructor(
    private orderService: OrderService,
    private paymentService: PaymentService,
    private inventoryService: InventoryService
  ) {}

  async createOrder(orderData: OrderDTO) {
    // Appels directs dans le même processus
    const inventory = await this.inventoryService.checkStock(orderData.items);
    const payment = await this.paymentService.processPayment(orderData.payment);
    const order = await this.orderService.createOrder(orderData);
    
    // Transaction atomique sur une seule DB
    return order;
  }
}

Mise en œuvre

1. Organiser le code en couches logiques claires (présentation, métier, données) même dans un monolithe
2. Définir des modules avec des frontières bien établies pour faciliter une éventuelle migration
3. Centraliser la configuration et les dépendances dans un seul fichier de build
4. Mettre en place des tests d'intégration exploitant la simplicité d'une base de code unique
5. Configurer un pipeline CI/CD pour construire et déployer l'artefact unique
6. Monitorer les métriques de performance et identifier les points de friction avant qu'ils deviennent critiques
7. Planifier la stratégie de scalabilité (vertical scaling ou décomposition future)

Outils associés

• Spring Boot, Django, Ruby on Rails : frameworks optimisés pour monolithes
• Docker : conteneurisation du monolithe pour déploiement cohérent
• Nginx/Apache : reverse proxy pour gérer la charge
• New Relic, Datadog : monitoring de performance des monolithes
• SonarQube : analyse de qualité de code pour maintenir une base saine
• Flyway, Liquibase : gestion de migrations de schéma unique

L'architecture monolithique reste pertinente en 2024 pour de nombreux cas d'usage : applications à trafic modéré, équipes réduites, contextes métier en exploration. La clé réside dans la qualité du découpage interne et l'anticipation des besoins de scalabilité. Un monolithe bien conçu peut évoluer vers une architecture distribuée lorsque la complexité métier et le volume le justifient, en s'appuyant sur les modules comme candidats naturels à l'extraction.