L’architecture logiciel est l’Art des choix de conception de haut niveau et des normes techniques, y compris des normes de codage de logiciel, des outils et des plates-formes, c’est une discipline primordiale que n’importe quel projet de développement et digitalisation informatique doit prendre en considération pour assurer la fiabilité, l’évolutivité et l’extensibilité.
D’après mon expérience professionnelle tout au long des dizaines de projets, j’ai constaté que la plupart des complexités et des boucles de maintenance infinies viennent d’une mauvaise structure du projet ou d’un travail de développement qui ne suit pas le minimum des règles d’architecture et des bonnes pratiques.
Dans cet article, j’ai décidé de partager avec vous, un résumé et vue d’ensemble, auteur de la plupart des aspects théoriques et techniques à noter dans votre démarche et projet logiciel.
Les choix d'architecture :
1. Architecture en couches
Le modèle d’architecture le plus courant et le modèle qui consiste à découper l’application en plusieurs couches, également appelé modèle d’architecture N-Tier. Ce model correspond aux structures de communication et d’organisation traditionnelles de la plupart des entreprises, ce qui en fait un choix naturel pour la plupart des efforts de développement d’applications métier.
Les couches principales sont décrites comme suit :
- Couche de présentation (interface utilisateur)
- Couche application (ou couche métier) : c’est la couche service qui traite les commandes, prend des décisions logiques et des calculs, elle déplace et traite également les données entre l’interface utilisateur et la couche données .
- Couche données : Ici les informations sont stockées et extraites d’une base de données ou d’un système de fichiers.
| Avantages | Inconvenients |
| - Développement facile et rapide . | - Peut avoir un impact négatif sur la performance . |
| - Facile à tester et à mettre en place . | - Étroitement couplées et monolithiques => Déploiement lent et lourd . |
2. Architecture Client Serveur :
L’architecture client-serveur est un système d’architecture de ressources centralisé, où le serveur contient toutes les ressources (services…) partagées avec ses clients à la demande. Le client et le serveur peuvent être sur le même réseau ou sur des réseaux différents .
Vous pouvez distinguer 3 types d’architectures client-serveur:
- Architecture 1-tier : la couche Présentation, métier et couches d’accès aux données, au sein d’un même package logiciel , ex : l’application bureau MS Office .
- Architecture 2–tiers : dans cette architecture la couche présentation (l’interface utilisateur) est stockée sur la machine cliente, on trouve 2 cas possibles :
- Client léger : Si le Logique métier et la couche de données sont gérées sur le serveur (cas abordable).
- Client lourd : Si le Logique métier et la couche de données sont situés côté client.
- Architecture 3-tiers : L’architecture est divisée en 3 parties, à savoir, la couche présentation (Serveur Web), la couche métier (Serveur d’application) et la couche de données (Serveur de la base de données) , c’est une architecture couteuse mais garantit une bonne performance , maintenance et flexibilité.
3. Architecture MVC :
MVC est un modèle pour l’architecture d’une application logicielle. Il sépare une application en trois composants:
- Modèles : pour le traitement des données et logique métier
- Contrôleurs : pour intercepter et gérer les actions et les requêtes de l’utilisateur
- Vues : pour la gestion des objets d’interface utilisateur graphique et de la présentation.
Cette séparation entraîne le traitement des demandes utilisateur comme suit:
- Le navigateur (sur le client) envoie une demande de page au contrôleur sur le serveur.
- Le contrôleur extrait les données dont il a besoin du modèle pour répondre à la demande.
- Le contrôleur donne les données récupérées à la vue.
- La vue est rendue et renvoyée au client pour que le navigateur l’affiche.
Ce processus est illustré à la figure ci-dessous.
| Avantages | Inconvenients |
| - Développement rapide et maintenable. | - La couche Controller et la couche View sont parfois trop couplées, ce qui dégrade la réutilisation du code. |
| - Possibilité de fournir plusieurs vues. . | - Difficulté d'utilisation de MVC avec les interfaces utilisateurs modernes (ex : React …) => Adopter l’approche Flux . |
| - La séparation de la View-Model, améliore la réutilisation du code. |
4. Architecture orientée service (SOA) :
C’est une approche architecturale qui consiste à décomposer l’application en plusieurs composants distincts , ces composants fournissent des services aux autres composants via un protocole de communication sur un réseau.
Un service est une unité discrète de fonctionnalités telle que la validation du paiement, la création d’un compte utilisateur ou un service de consultation du compte … qui peut être accessible à distance, exploitable et mise à jour indépendamment des autres.
On peut définir quatre propriétés pour ses services :
- Il représente logiquement une activité métier avec une préoccupation précisée.
- Il est autonome et indépendant des autres services.
- C’est une boîte noire pour ses consommateurs (Client,FrontEnd …)
- Il peut se composer d’autres services sous-jacents.
Il existe trois rôles principaux dans l’architecture orientée services :
- Service provider : c’est Le fournisseur et le responsable du service et l’organisation qui met un ou plusieurs services à la disposition des tiers.
- Service Repository / Service Registry: Pour annoncer des services, le fournisseur peut les publier dans un registre , accompagnés d’un contrat de service précisant la nature du service, son utilisation, les exigences du service et les frais facturés.
- Service consumer : C’est le consommateur du service qui peut localiser les métadonnées du service dans le registre et développer les composants clients nécessaires pour lier et utiliser le service.
| Avantages | Inconvenients |
| - Réutilisation des services. | - Un investissement énorme est requis pour la SOA. |
| - Faible couplage des services et Maintenance facile | - Gestion complexe des services : |
| - créer une application complexe en combinant des services dans différentes plateformes. | lorsque les services interagissent, ils échangent des messages en tâches. le nombre de messages peut aller en millions ce qui diminue les performances tout en augmentant la charge et le temps de réponse. |
| - Fiabilité, Disponibilité et Evolutivité . |
Implémentation de la SOA :
L’Architecture orientée service peut être implémentée et réalisée à l’aide d’un large éventail de technologies, notamment:
- Les Web services SOAP ou REST .
- Service Messaging comme ActiveMQ , JMS
- Remote procedure call via RMI , CORBA…
👉 Extension vers L’architecture MicroServices :
Les MicroServices constituent en quelque sorte une nouvelle approche de réalisation et de mise en œuvre de la SOA , qui permet d’affiner certains des principes, notamment la granularité des services , SAO standard se concentre sur la réutilisabilité du service , tandis que les Microservices essaient maximiser le découplage via des contextes bornés (Bounded Context : couplage d’un composant et de ses données sous la forme d’une unité unique d’une préoccupation spécifique (Ventes, Achats…) avec des dépendances minimales).
- La capture ci-joint , résume un schéma Micro-service d’implémentation Spring-Cloud Netflix :
- Eureka : une implémentation spring-netflix du Service-Registry, pour la localisation de services et l’équilibrage de la charge entre plusieurs instances du même service .
- Zuul : une implémentation du Front-Controller , c’est la porte d’entrée et le routeur de toutes les requêtes client .
- Ribbon : une implémentation du service-bus entre les micro-services métier, qui permet la découverte des autres services et l’équilibrage de charge d’une manière dynamique .
- Zipkin : est un système de traçage distribué. Il aide à collecter les données de synchronisation nécessaires pour résoudre les problèmes de latence dans les Micro-services ..
5. Architecture de la plateforme SAAS (Software as a service) :
Le logiciel en tant que service est une tendance croissante en tant que canal de distribution de logiciels. C’est un modèle de licence et de distribution dans lequel le logiciel est sous licence par abonnement et hébergé de manière centralisée. Les utilisateurs peuvent y accéder à l’aide des navigateurs Web.
Ce modèle de livraison est commun pour de nombreuses applications d’entreprise, y compris les logiciels de bureautique, messagerie, les logiciels de gestion, la virtualisation, etc. Il fait partie de la nomenclature Cloud .
- Exemples SAAS : GoogleDocs , MS Office 365 …
Considérations de conception pour une plate-forme SaaS :
- Assurer l’évolutivité et l’extensibilité .
- Haute disponibilité .
- Assurance des SLA (contrats de niveau de service)
- Prise en charge des accès simultanés tout en garantissant la fiabilité et la confidentialité .
| Avantages | Inconvénients |
| - Économique : Le modèle d’abonnement au service, permet aux entreprises d'éliminer le budget de configuration d’infrastructure . | - Manque de contrôle : Les applications SaaS étant hébergées sur le serveur Web du fournisseur, donc vous n’avez pratiquement aucun contrôle sur le comportement des logiciels que vous utilisez. |
| - Sécurité et Disponibilité: Le consommateur d’une application conçue en mode SaaS, ne devra pas avoir aucun soucis de la façon dont les données sont verrouillées. C’est sécurisé dans le Cloud . | - Performance : Une application interne, client lourd ou sur site fonctionnera toujours plus rapidement qu'un produit livré sur Internet. |
| - Confidentialité des données : Lors de la sélection d'un produit SaaS et avec l'avènement du GDPR, les entreprises doivent accorder une attention particulière comment une implémentation SaaS stocke et traite ses données sensibles dans le cloud. |
Les Modèles de communication
Il est primordial d’avoir connaissance sur les modèles de communication à choisir pour mettre en place une solution d’interopérabilité et d’échange entres les différentes composants (généralement des services) de votre application, à savoir en bref :
- Message Queue : RabbitMQ, ActiveMQ …
- Web API : SOAP , REST .
- Remote procedure call (RPC) : RMI …
- Entreprise Service Bus (ESB) : utilisé en SOA , c’est une architecture logicielle qui relie tous les services entre eux ou entre le fournisseur du service et le client via une infrastructure bus , ce dernier peut être implémenté comme un TransctionManager, SecurityManager ou Gateway .
Conception du Squelette et Socle du projet :
Savoir comment préparer et concevoir le socle du projet est une capacité incontournable pour un architecte ou un ingénieur logiciel, c’est la où commence la première phase de la réalisation qui définit le squelette technique du projet, une mauvaise conception de ce dernier, entraine une suite de travail de développement plein de complexité et difficile à maintenir principalement pour les autres membres qui nécessitent une structure complète, bien organisée et facile comprendre.
Ci-dessous les phases à prendre en considération pour la mise en place du socle d’un projet (prennent un projet Java comme exemple) :
- Bien étudier le choix de l’architecture à adopter suite à une analyse du besoin : Client-Serveur , MVC , Micro Services … , c’est une étape décisive , N’oubliez pas que le Budget du client présente un facteur majeur pour le choix d’une architecture.
- Bien choisir les technologies et ses versions : Java Spring, .NET … , parmi les critères à prendre en considération on peut citer l’exhaustivité de la documentation, la taille de sa communauté , le niveau de maitrise de la technologie, et la nature de l’environnement technique du client (nature des serveurs, base de données …)
- Analyser et Définir la description globale du projet, de ses dépendances et le type du packaging via un outil de Build (Maven , Gradle …)
Exemple d’une description standard Maven xml :
- Analyse et Création de l’arborescence du projet et de ses packages en fonction du type d’architecture choisie, généralement concevoir des packages en fonction des différentes couches ou modules du projet.
Exemple standard du squelette :
- Configuration des fichiers Logs et politique de journalisation : Logback …
- Configuration et Mise en place des Tests (Test Unitaires, TDD, Tests automatisées …) : Junit, Selenium …
- Configuration et Mise en place d’un outil de documentation : Swagger, Javadocs…
- Configuration et Mise en place de l’intégration continue : Jenkins Sonar Docker…
👉 Après cela, vient la phase d’implémentation et du développement des différents modules et couches du projet (réalisation suite au Conception UML), généralement en commence par la conception et le développement de la couche DAL (Data Access Layer) , une mauvaise conception de celle-ci provoque une complexité du code et une dégradations de performance .
Architecture et conception du code :
1. Les principes SOLID :
Lorsque le développeur construit un logiciel suivant la mauvaise conception, le code peut devenir inflexible et plus fragile, de petites modifications du logiciel peuvent entraîner des bogues. Pour ces raisons, nous devrions suivre les principes SOLID.
SOLID est une norme de codage pour développer les logiciels de manière appropriée afin d’éviter une mauvaise conception , Lorsqu’il est appliqué correctement, votre code est plus extensible, logique et plus facile à lire.
Pour comprendre les principes de SOLID, vous devez connaître clairement l’utilisation de l’interface en programmation .
S : Single Responsibility Principle :
Une classe ne devrait servir qu’à une seule préoccupation, Toutes les méthodes et propriétés doivent toutes viser le même objectif. Lorsqu’une classe a plusieurs objectifs ou responsabilités, elle devrait être transformée en une nouvelle classe.
O : Open-closed Principle :
Les classes, modules ou fonctions … doivent être ouvertes pour l’extension, mais fermées pour la modification , elles peuvent être étendues sans modifier réellement le contenu de la classe que vous étendez. Si nous pouvions suivre suffisamment ce principe, il est possible de modifier ensuite le comportement de notre code sans jamais toucher à un morceau de code original .
L : Liskov Substitution Principle
Le principe définit que les objets d’une super-classe doivent pouvoir être remplacés par des objets de ses sous-classes sans interrompre l’application.
Une méthode redéfinie d’une sous-classe doit accepter les mêmes valeurs d’entrée et de sortie que la méthode de la superclasse .
I : Interface Segregation Principle :
Un client ne doit pas être forcé d’implémenter une interface qu’il n’utilise pas.
Cette règle signifie que nous devrions casser nos interfaces dans de nombreuses plus petites pour mieux répondre aux besoins exacts de nos clients , les interfaces considérées comme contrat de services .
D : Dependency Inversion Principle :
Les classes de haut niveau ne doivent pas dépendre des classes de bas niveau. Les deux devraient dépendre des abstractions.
Les abstractions ne doivent pas dépendre des détails. Les détails devraient dépendre des abstractions.
Ou simplement: Dépendre des abstractions, non pas sur des implémentations 😉 .
Voir les principes SOLID « in-a-nutshell »
2. Les Design Patterns
Les modèles de conception (Design Patterns) , comme aspect incontournable en architecture logiciel , représentent les bonnes pratiques utilisées par les développeurs de logiciels expérimentés orientés objet , ils proposent des solutions rapides , efficaces et sophistiquées aux problèmes généraux rencontrés .
Ces Design Patterns peuvent être classée en 3 Catégories , dans chaque catégorie on décrit les principaux et les fréquemment utilisées :
- Patterns de création qui traite le mécanisme de création des objets et donner au programme plus de flexibilité pour décider quels objets doivent être créés pour un cas d’utilisation donné , à savoir : Factory , Builder , Prototype , Singleton.
- Patterns de structure qui facilite la conception du code en identifiant un moyen simple et extensible pour réaliser des relations entre les entités (Classes, interfaces…) ,à savoir : Facade , Proxy , Adapter.
- Patterns de comportement pour concevoir spécifiquement la communication entre les objets, à savoir : Strategy , Observer , chain of responsibility.
Conclusion
Dans cet article, nous avons abordé d’une manière générale plusieurs périmètres et les principaux aspects de l’architecture logiciel , à savoir les différents modèles d’architectures, les types de communications possibles au sein d’une architecture, les éléments à prendre en considération lors de la préparation d’un socle du projet, et enfin , un ensemble des bonnes pratiques de la phase du développement logiciel , c’est une liste des notes importantes, à évoquer dans vos projets logiciels .
Reconnaître le besoin est la condition première de l’architecture.Et quand je travaille sur un problème, je ne pense jamais à la beauté. Mais quand j’aurai fini, si la solution n’est pas belle, je sais que c’est faux. 😉
Auteur : yassine Abainou