Panorama des patterns architecturaux fondamentaux, de la couche monolithique aux systèmes distribués.
« Le but d'une bonne architecture est de minimiser les ressources humaines nécessaires pour construire et maintenir un système. » Une architecture n'est pas une technologie — c'est une décision sur ce qui peut changer facilement et ce qui doit rester stable. Elle sépare la politique (les règles métier) des détails (les frameworks, les bases de données, le réseau).
Pas sûr de quelle architecture choisir ? Répondez à 5 questions couvrant stade, domaine, organisation, NFR et coût du changement pour obtenir une recommandation personnalisée.
Tout le système est déployé comme une seule unité. Simple à développer initialement, difficile à faire évoluer à grande échelle. La métaphore : un bloc de pierre — solide, mais sculptez-en une partie et vous risquez de tout fissurer.
Organisation en couches horizontales : Présentation → Logique Métier → Accès aux données → Base de données. Uncle Bob critique le fait que les couches inférieures dictent souvent les couches supérieures — le schéma DB ne doit pas dicter les entités métier.
« Les détails doivent dépendre des politiques, jamais l’inverse. »
Séparation de la vue, du modèle et du contrôleur/présenteur/viewmodel. Patterns de présentation plutôt qu’architecturaux au sens strict, mais fondamentaux dans la structuration du code d’interface.
Cercles concentriques : Entities → Use Cases → Interface Adapters → Frameworks. La règle de dépendance est absolue : les dépendances ne pointent QUE vers l’intérieur. La DB, le web, les frameworks sont des détails remplaçables.
« Le web est un détail. La DB est un détail. » — Clean Architecture
Similaire à Clean Architecture (Jeffrey Palermo). Le Domain Model est au centre, entouré de couches de services. L’infrastructure est toujours à l’extérieur. Les interfaces définissent les contrats entre couches.
Le domaine au centre communique via des Ports (interfaces). Les Adapters implémentent ces ports pour le monde extérieur (HTTP, DB, Queue…). Inventée par Alistair Cockburn. Parfait pour la testabilité : le domaine ne connaît rien de l’extérieur.
Eric Evans. L’architecture suit le domaine métier : Bounded Contexts, Aggregates, Entities, Value Objects, Domain Events. Ubiquitous Language : le code parle le même langage que les experts métier. Souvent combiné avec Hexagonale ou Clean.
Services réutilisables communiquant via un ESB (Enterprise Service Bus). Précurseur des microservices, souvent plus lourd. Populaire dans les grandes entreprises années 2000. L’ESB peut devenir un point de défaillance unique.
Services petits, indépendants, déployables séparément. Chaque service possède sa propre base de données. Communication via REST, gRPC ou messages. Scalabilité fine, mais complexité opérationnelle élevée. La métaphore : un banc de poissons vs un requin.
Martin Fowler : « Ne commencez pas avec les microservices. »
Fonctions déployées à la demande (AWS Lambda, Azure Functions). L’infrastructure est totalement abstraite. Facturation à l’usage. Idéal pour les charges variables. Limite : cold starts, état difficile à gérer, vendor lock-in.
Les composants communiquent via des événements asynchrones (Kafka, RabbitMQ). Découplage fort : le producteur ignore qui consomme. Parfait pour les flux temps réel. La métaphore : la radio FM — elle émet sans savoir combien d’auditeurs l’écoutent.
L’état du système est reconstruit en rejouant une séquence d’événements immuables. Auditabilité totale. La métaphore : un journal comptable — on ne rature jamais, on passe une écriture de correction. Souvent combiné avec CQRS.
Séparer les modèles d’écriture (Commands) et de lecture (Queries). Optimiser chaque côté indépendamment. La lecture peut avoir ses propres vues dénormalisées. Complexité accrue mais performances et scalabilité supérieures.
Un noyau stable expose des points d’extension. Les fonctionnalités sont des plugins indépendants. Uncle Bob : le système central ne dépend PAS des plugins, c’est l’inverse. Exemple canonique : un IDE avec ses extensions.
« Protégez le noyau des détails volatils. »
Décomposition en composants autonomes, réutilisables, avec interfaces claires. Chaque composant encapsule son état et sa logique. Fondement des frameworks modernes (React, Vue, Web Components). Favorise la réutilisabilité.
Un seul déploiement mais une structure interne fortement modulaire avec frontières claires entre modules. Le meilleur des deux mondes : simplicité opérationnelle du monolithe + séparation des préoccupations des microservices. Recommandé comme étape avant microservices.
Couche d’infrastructure dédiée à la communication inter-services (Istio, Linkerd). Gère : la découverte, le load balancing, le chiffrement, l’observabilité. La logique réseau sort du code applicatif pour aller dans le mesh.
Gestion des transactions distribuées sans 2PC. Séquence de transactions locales compensées en cas d’échec. Deux modes : Choreography (événements) ou Orchestration (saga orchestrateur central). Complexe mais incontournable en microservices.
Application du principe microservices au frontend. Chaque équipe possède sa slice verticale complète : backend + frontend. Indépendance de déploiement, de technologie. Module Federation (Webpack) en est l’implémentation moderne.