Une application, trois formes
Un seul déploiement
Simple à construire, tester et déployer, mais chaque modification livre toute l'application et tout évolue ensemble.
Monolithe ou microservices ?
Architecture monolithique
Base de code et unité de déploiement unifiées. Tous les composants sont fortement couplés et déployés ensemble.
Avantages
- Simple à développer et déployer initialement
- Débogage et tests plus faciles
- Meilleures performances (pas de latence réseau)
- Complexité opérationnelle réduite
Défis
- Difficile de scaler des composants spécifiques
- Grande base de code difficile à maintenir
- Cycles de déploiement longs
- Verrouillage de la stack technologique
Quand l'utiliser : Applications petites à moyennes, startups, MVPs, équipes avec maturité DevOps limitée
Architecture microservices
Application composée de petits services déployables indépendamment. Chaque service possède ses données et communique via API ou messages. En savoir plus sur les microservices sur Azure.
Avantages
- Déploiement et mise à l'échelle indépendants
- Diversité technologique par service
- Isolation des pannes (une défaillance de service ne fait pas tout planter)
- Autonomie des équipes et développement parallèle
Défis
- Gestion complexe des systèmes distribués
- Préoccupations de latence et fiabilité réseau
- Transactions distribuées et cohérence des données
- Surcharge opérationnelle (surveillance, journalisation)
Quand l'utiliser : Grandes entreprises, applications haute scalabilité, équipes avec expertise DevOps, exigences polyglottes
Autres styles d'architecture
Architecture événementielle
Les systèmes communiquent via des événements (changements d'état). Les producteurs publient des événements ; les consommateurs réagissent de manière asynchrone. Permet un couplage faible et un traitement en temps réel.
- Notification d'événement : Événements légers signalant que quelque chose s'est passé
- Transfert d'état par événement : Les événements contiennent toutes les données nécessaires
- Event sourcing : Stocker tous les changements d'état comme événements immuables
- CQRS : Séparer les modèles de lecture et d'écriture avec synchronisation par événements
Services Azure : Event Grid, Event Hubs, Service Bus, Cosmos DB change feed
Architecture en couches (N-Tier)
Modèle classique organisant le code en couches horizontales avec des dépendances descendantes.
- Couche de présentation : UI, contrôleurs, view models
- Couche de logique métier : Modèles de domaine, règles métier, workflows
- Couche d'accès aux données : Repositories, ORMs, contextes de base de données
- Préoccupations transversales : Journalisation, cache, authentification
Quand l'utiliser : Applications d'entreprise traditionnelles, domaines bien compris, équipes familières avec l'approche en couches
Architecture hexagonale (Ports & Adaptateurs)
Logique métier au centre, dépendances externes (bases de données, API, UI) comme adaptateurs. Les ports définissent les contrats, les adaptateurs les mettent en œuvre.
- Domaine central : Logique métier pure, sans dépendances de framework
- Ports : Interfaces définissant comment le monde externe interagit avec le noyau
- Adaptateurs : Mises en œuvre pour bases de données, API web, files de messages
- Bénéfices : Testabilité, indépendance technologique, frontières claires
Architecture serverless
Calcul événementiel, auto-scaling sans gestion de serveurs. Paiement uniquement pour le temps d'exécution.
- Azure Functions : Déclencheurs HTTP, timers, déclencheurs queue/blob
- Logic Apps : Orchestration de workflows avec concepteur visuel
- Durable Functions : Workflows avec état et checkpointing
- API Management : Gateway pour API serverless
Quand l'utiliser : Charges de travail variables, traitement d'événements, scénarios sensibles aux coûts, prototypage rapide