Patron d'architecture
Un patron d'architecture (ou architecture pattern en anglais) est un modèle conceptuel pour structurer l'architecture d'une application ou d'un système. Il fournit des solutions éprouvées pour organiser les composantes principaux d'un système et définir leurs relations, souvent à un niveau plus élevé que les patrons de conception, se concentrant davantage sur les objets et leurs interactions spécifiques.
Les patrons d'architecture aident les architectes et les développeurs à :
- Structurer des applications complexes de manière cohérente,
- Encadrer les décisions de conception autour des besoins en mise à l'échelle, maintenabilité et performances,
- Faciliter la communication autour de l'architecture globale grâce à des schémas bien connus.
Liste des patrons d'architectures les plus populaires
| Patron d'architecture | Description | |
|---|---|---|
| Broker Architecture (Architecture Broker) | L'architecture Broker est un patron distribué, souvent utilisé dans des applications complexes intégrant différents services distribués. Elle repose sur
un courtier (broker), une composante centrale servant d'intermédiaire pour orchestrer la communication entre les différentes parties du système (services,
applications ou composantes). Voici ses caractéristiques principales :
L'architecture Broker est couramment utilisée dans les systèmes middleware, comme les systèmes de messagerie (RabbitMQ, Apache Kafka) ou les applications de gestion de transactions. |
|
| Clean Architecture (Architecture propre) | L'architecture Clean (ou architecture propre), popularisée par Robert C. Martin, est un patron visant à structurer le code en couches strictement séparées pour
isoler la logique métier et permettre une grande flexibilité pour les adaptations futures. Voici ses principes principaux :
|
|
| Client-Serveur | Organisation classique où les clients envoient des requêtes à un serveur centralisé leur retournant les résultats. Couramment utilisée pour les applications Web et les applications réseau. | |
| CQRS (Command Query Responsibility Segregation) | Sépare les opérations de lecture (Query) et d'écriture (Command) sur les données, souvent utilisé avec les architectures event-driven pour améliorer les performances et la mise à l'échelle dans les systèmes complexes. | |
| DDD (Domain-Driven Design) | L'architecture DDD se concentre sur le domaine métier et modélise les entités, les agrégats et les valeurs en fonction des règles métiers. Le DDD est souvent appliqué en complément d'autres architectures (comme l'architecture hexagonale ou l'architecture propre) et introduit des concepts tels que les agrégats, les entités et les répertoires pour encapsuler le domaine métier. | |
| Event-Driven Architecture (architecture pilotée par les événements) | Les composantes communiquent entre eux via des événements. Lorsqu'une composante déclenche un événement, les composantes intéressés y réagissent sans être directement connectés. Favorise la modularité et est souvent utilisée pour les systèmes en temps réel ou les systèmes distribués. | |
| Event Sourcing | L'Event Sourcing est un patron d'architecture dans lequel les changements d'état d'une application sont modélisés comme une séquence d'événements immuables.
Au lieu d'entreposer uniquement l'état actuel de l'entité, l'Event Sourcing garde en mémoire toutes les modifications y étant été apportées sous forme d'événements.
|
|
| Hexagonal Architecture (Architecture Hexagonale) | L'Architecture Hexagonale est également connue sous le nom de Ports and Adapters. Popularisée par Alistair Cockburn, cette architecture vise à isoler le coeur de l'application (logique métier) des périphériques (bases de données, API, interfaces utilisateur). L'application est construite autour d'un noyau central, avec des «ports» (interfaces) et des «adaptateurs» (implémentations) connectant l'application à des systèmes externes. En ASP.NET Core, cela signifie que la logique métier est indépendante des détails d'implémentation, facilitant ainsi les tests et les changements. | |
| Layered Architecture (architecture en couches) | Divise le système en couches hiérarchisées, comme la couche de présentation, la couche métier et la couche de données. Chaque couche ne communique qu'avec celle lui étant directement inférieure, ce qui améliore la maintenabilité. | |
| Microservices | Structure l'application comme un ensemble de services indépendants, chacun étant responsable d'une fonctionnalité particulière. Les microservices communiquent généralement via des API REST ou des files de messages et permettent un déploiement indépendant, favorisant la mise à l'échelle. | |
| Monolithic Architecture (Architecture Monolithique) | L'architecture monolithique consiste à regrouper toutes les fonctionnalités d'une application dans une seule unité ou bloc fonctionnant comme une seule entité.
|
|
| MVC (Model-View-Controller) | Sépare l'application en trois composantes principaux : le Modèle (logique métier et données), la Vue (interface utilisateur) et le Contrôleur (coordonne les interactions entre la vue et le modèle). Utilisé dans les applications Web et de bureau pour améliorer la maintenabilité et la séparation des préoccupations. | |
| Onion Architecture (Architecture en Oignon) | Proche de l'architecture hexagonale et de l'architecture propre, l'Onion Architecture est centrée sur la logique métier, formant le noyau de l'application. Chaque couche concentrique autour du noyau ajoute une couche de dépendances (cas d'utilisation, services, infrastructure). L'application est ainsi divisée en couches indépendantes avec une stricte séparation des préoccupations. | |
| N-Tier Architecture | L'architecture N-Tier est une architecture en couches dans laquelle une application est divisée en plusieurs couches ou niveaux (par exemple, présentation,
logique métier, accès aux données).
Exemple : Langage de programmation - ASP 3.0 - VB/ASP (architecture en N-tiers) |
|
| Peer-to-Peer Architecture | L'architecture Peer-to-Peer (P2P) permet aux noeuds du réseau d'agir à la fois comme clients et serveurs. Les ressources sont partagées entre les
pairs sans dépendance d'un serveur central.
|
|
| Pipes and Filters | L'architecture Pipes and Filters divise le traitement d'une tâche en une série d'étapes (ou filtres) reliées par des canaux de communication (pipes).
|
|
| Publish-Subscribe Architecture (architecture de publication-abonnement) | L'architecture Publish-Subscribe permet aux services d'émettre (publish) des messages dans un canal auquel d'autres services peuvent s'abonner
(subscribe) sans dépendance directe entre les services producteurs et consommateurs.
| |
| Serverless Architecture (architecture sans serveur) | L'architecture Serverless déplace la gestion de l'infrastructure vers le fournisseur d'infonuagique, permettant aux développeurs de se concentrer
uniquement sur le code sans se soucier des serveurs sous-jacents.
|
|
| Service Mesh | Le Service Mesh est une architecture pour gérer la communication entre les microservices dans un environnement distribué. Un service Mesh s'occupe des
besoins de mise en réseau, de sécurité et de surveillance des microservices.
|
|
| SOA (Service-Oriented Architecture) | L'architecture orientée services (SOA) divise les applications en services réutilisables et modulaires, où chaque service est indépendant et communique
via des protocoles standardisés.
|
|
| Space-Based Architecture (Architecture orientée espace) | L'architecture Space-Based est conçue pour les applications nécessitant une grande mise à l'échelle et vise à éviter les points de congestion (bottlenecks)
en décentralisant le stockage et le traitement des données.
|
Différences avec les patrons de conception
Contrairement aux patrons de conception (comme Singleton, Observer, Decorator), concernant des solutions au niveau du code et des objets, les patrons d'architecture opèrent à une échelle plus élevée, souvent en orientant la structure globale de l'application et en tenant compte des besoins opérationnels comme la gestion des performances, la tolérance aux pannes et la modularité.
Avantages des patrons d'architecture
- Standardisation des structures : ils fournissent des modèles éprouvés et standardisés pour organiser les composants d'une application.
- Simplicité de la communication : en utilisant des schémas connus, ils facilitent la communication entre les équipes.
- Amélioration de la mise à l'échelle et de la maintenabilité : ils permettent d'adapter plus facilement le système aux changements ou à l'évolution des besoins.
Dernière mise à jour : Vendredi, le 1er novembre 2024