Architectures et modèles architecturaux des logiciels
Les architectures topologiques
L’architecture distribuée
Une architecture distribuée répartit les composants d’un logiciel entre plusieurs machines qui communiquent par le réseau. Cette organisation impose de tenir compte des délais de communication, des pannes qui ne touchent qu’une partie du système, de la cohérence des données et de la capacité à continuer de fonctionner malgré certaines défaillances. Ces enjeux sont essentiels pour comprendre les architectures microservices et certaines architectures orientées événements.
L’architecture monolithique
Dans une architecture monolithique, l'ensemble des fonctionnalités du logiciel sont réunies dans une même application, construite et déployée comme une seule unité. Cette organisation facilite généralement le développement, les tests et le déploiement au démarrage du projet. À mesure que le logiciel grandit, ces activités peuvent toutefois devenir plus complexes si ses différentes parties sont fortement couplées.
L’architecture N-tiers
L’architecture N-tiers répartit l’application entre plusieurs tiers d’exécution, par exemple un client Web, un serveur applicatif et un serveur de base de données. Chaque tiers peut s’exécuter dans un processus ou un environnement distinct et communiquer avec les autres au travers du réseau. Alors que les couches organisent logiquement les responsabilités du code, les tiers décrivent la manière dont les différentes parties de l’application sont déployées et exécutées.
L’architecture microservices
L’architecture microservices répartit le logiciel en plusieurs services, généralement organisés autour de capacités métier. Ces services communiquent entre eux et peuvent être développés et déployés indépendamment. Chacun maîtrise ses propres données et peut évoluer à son rythme. Cette autonomie apporte de la souplesse, mais les échanges entre services rendent plus complexes la gestion des données, le suivi des traitements et l’exploitation du système.
L’architecture serverless
Une architecture serverless permet d’exécuter du code sans avoir à gérer directement les serveurs qui l’hébergent. Les traitements peuvent être déclenchés à la demande, par exemple par une requête HTTP ou l’arrivée d’un message. Dans l’écosystème .NET, Azure Functions permet de développer ce type de traitements. Selon le mode d’hébergement choisi, la plateforme adapte les ressources à la charge. Cette simplicité d’exploitation s’accompagne toutefois de contraintes, notamment sur les temps de démarrage et la durée d’exécution de certains traitements.
Les architectures logiques
L’architecture en couches
L’architecture en couches répartit les responsabilités du logiciel entre plusieurs ensembles logiques, tels que la présentation, les traitements applicatifs, le métier, l’accès aux données, etc. Chaque couche possède un rôle précis et utilise généralement les services de la couche située en dessous d’elle.
L’architecture hexagonale
Également appelée Ports and Adapters, l’architecture hexagonale place la logique métier au cœur de l’application, et cherche à l’isoler des technologies extérieures. Les ports définissent les interactions avec ce cœur ; les adaptateurs les mettent en œuvre pour communiquer, par exemple, avec une interface Web, une base de données ou un service distant. Cette organisation limite les dépendances de la logique métier envers ASP.NET Core, Entity Framework Core et les autres composants logiciels.
L’Onion Architecture
L’Onion Architecture représente l’application sous forme de couches concentriques. Le domaine occupe le centre, entouré notamment des services applicatifs, puis de l’infrastructure. Les dépendances de code pointent vers le centre : les couches internes ne dépendent pas des couches externes. Les règles métier peuvent ainsi être définies indépendamment des détails techniques (tels que l’accès aux données ou l’interface utilisateur).
La Clean Architecture
La Clean Architecture vise à rendre les règles métier et les cas d’utilisation indépendants de l’interface utilisateur, de la base de données et des frameworks. Elle repose sur une règle centrale : les dépendances du code sont orientées vers les couches internes, qui contiennent les règles métier et les cas d’utilisation. Ainsi, elle partage de nombreux principes avec l’architecture hexagonale et l’Onion Architecture.
La Vertical Slice Architecture
La Vertical Slice Architecture organise le code par fonctionnalité ou par cas d’utilisation. Chaque tranche verticale regroupe les éléments nécessaires à une opération, par exemple la création ou la consultation d’une fiche produit. Cette organisation renforce la cohésion autour de chaque fonctionnalité, et peut limiter les répercussions d’une modification sur le reste de l’application.
Le monolithe modulaire
Le monolithe modulaire conserve une application et un déploiement uniques, tout en organisant le logiciel en modules métier aux responsabilités clairement définies. Chaque module maîtrise l’accès à ses données et expose des interfaces explicites aux autres modules. Cette architecture permet de limiter le couplage entre les modules, tout en conservant la simplicité de déploiement d’un monolithe.
Architectures structurelles
L’architecture MVC
L’architecture MVC (Model-View-Controller) répartit les responsabilités de l’interface entre le modèle, qui représente les données et les comportements nécessaires au traitement, les vues, chargées de l’affichage, et les contrôleurs, qui reçoivent les requêtes et coordonnent les actions à exécuter. Elle est notamment mise en œuvre avec ASP.NET Core MVC. L'architecture MVC organise principalement la partie Web du logiciel et peut s’intégrer à une architecture plus globale.
CQRS
CQRS (Command Query Responsibility Segregation) sépare les opérations qui modifient l’état des données de celles qui consultent les données. Les commandes et les requêtes peuvent ainsi disposer de modèles et de traitements adaptés à leurs besoins respectifs. Cette séparation peut être mise en œuvre dans une même application, avec une seule base de données. Selon les besoins, les opérations de lecture et d’écriture peuvent aussi utiliser des bases de données distinctes.
L’Event Sourcing
L’Event Sourcing consiste à enregistrer la succession des événements qui ont modifié l’état d’un objet métier, plutôt que de conserver uniquement son état courant. Cet état peut ensuite être reconstruit en rejouant les événements. Cette approche permet de retracer les changements enregistrés, mais elle ajoute de la complexité ; son intérêt dépend donc des besoins du domaine métier.
L’architecture orientée événements
Dans une architecture orientée événements, les composants communiquent en publiant des événements qui signalent des faits survenus dans le système, et en réagissant aux événements qui les concernent. Cette communication, souvent asynchrone, réduit les dépendances directes entre les composants et facilite certains traitements distribués. Elle demande toutefois de gérer la cohérence des données, les traitements répétés, les erreurs et le suivi des échanges entre composants.
L’architecture orientée services
L’architecture orientée services (SOA) consiste à rendre certaines fonctions d’un système accessibles sous forme de services. Par exemple, un service chargé de calculer des tarifs peut être utilisé par un site Web, une application mobile et un logiciel interne. Chaque service définit comment les autres applications peuvent lui adresser une demande et recevoir une réponse : il s'agit du contrat d’échange. Cette organisation facilite aussi la communication avec des logiciels existants. Dans certaines mises en œuvre, les échanges entre services et les règles qui les encadrent sont gérés de façon centralisée. La SOA présente des points communs avec l’architecture microservices.
Les démarches de conception
Le Domain-Driven Design
Le Domain-Driven Design (DDD) est une démarche de conception particulièrement utile lorsque le domaine métier est complexe. Il encourage la collaboration avec les experts métier autour d’un langage partagé et propose des outils de modélisation tels que les entités, les objets-valeurs et les agrégats. Les contextes délimités définissent les périmètres dans lesquels chaque modèle métier s’applique. Le DDD ne constitue pas à lui seul une architecture technique complète, mais il influence le découpage du logiciel et la conception de son modèle métier.