Dans ce chapitre, nous aborderons l'architecture en couches (layered architecture), à quoi elle correspond et dans quels cas elle représente la solution parfaite pour une problématique de conception. À la fin du chapitre, je vous montrerai un exemple concret (le logiciel de gestion de projet Amaze), puis vous devrez résoudre un cas similaire en appliquant ce que vous avez appris.
Qu'est-ce que l'architecture en couches ?
Vous êtes-vous déjà demandé comment Google fait pour que Gmail fonctionne dans différentes langues à travers le monde ? Les utilisateurs peuvent utiliser Gmail tous les jours en anglais, en espagnol, en français, en russe et dans de nombreuses autres langues.
Google a-t-il développé des applications Gmail différentes pour chaque pays ? Bien sûr que non. Ils ont développé une version interne qui effectue tout le traitement des messages, puis ont développé différentes interfaces utilisateur externes qui fonctionnent dans de nombreuses langues.
Google a développé l'application Gmail en créant plusieurs couches :
Il existe une couche interne qui effectue tout le traitement.
Il existe une couche externe qui communique avec les utilisateurs dans leur langue.
Il existe également une autre couche qui interagit avec une base de données où sont stockés les messages électroniques des utilisateurs (des millions ou peut-être des milliards).
Gmail est divisé en au moins trois couches, chacune d'elles a une mission et elles existent séparément pour gérer différents processus à différents niveaux. C'est un excellent exemple d'architecture en couches.
Quelle est la structure d'une architecture en couches ?
Voyons à quoi cela ressemble :
Comme vous pouvez le voir sur le schéma ci-dessus, une architecture en couches standard comporte cinq parties :
La couche d'interaction avec l'utilisateur (User interaction layer) : C'est la couche qui interagit avec les utilisateurs par le biais d'écrans, de formulaires, de menus, de rapports, etc. C'est la couche la plus visible de l'application. Elle définit l'aspect de l'application.
La couche de fonctionnalités (Functionality Layer) : Il s'agit de la couche qui présente les fonctions, les méthodes et les procédures du système selon la couche des règles de gestion. Elle détermine comment les menus déroulants fonctionnent, comment les boutons fonctionnent et comment le système navigue entre les écrans.
La couche des règles de gestion (Business rules layer) : Cette couche contient des règles qui déterminent le comportement de l'ensemble de l'application, par exemple : « Si une facture est imprimée, il faut envoyer un courriel au client, sélectionner tous les articles vendus et diminuer leur stock dans le module de gestion des stocks. »
La couche du noyau de l'application (Application core layer) : Cette couche contient les principaux programmes, les définitions du code et les fonctions de base de l'application. Les programmeurs travaillent la plupart du temps sur cette couche.
La couche de la base de données (Database layer) : Cette couche contient les tables, les index et les données gérées par l'application. Les recherches et les opérations d'insertion/suppression/mise à jour sont exécutées ici.
Comment cela fonctionne-t-il en pratique ?
Un système ERP (comptes fournisseurs, comptes clients, gestion des stocks, gestion des RH, gestion de la production, gestion des fournisseurs, achats, trésorerie, finances, comptabilité, etc.) possède une couche d'interaction avec l'utilisateur pour chaque module : écrans, formulaires, menus, rapports. C'est ce que l'utilisateur voit et ce qu'il utilise.
La couche de fonctionnalités permet de naviguer dans les différents modules, de présenter des séquences d'écran à l'utilisateur et d'effectuer toutes les opérations de saisie de données.
La couche des règles de gestion détermine le comportement des modules de l'ERP : « Si un nouvel employé est entré dans les modules RH et paie, alors insérez un cours d'introduction dans le menu de formation de l'employé. »
La couche du noyau de l'application est l'endroit où se trouve tout le code du système. C'est là que les développeurs ajoutent des personnalisations et de nouvelles fonctionnalités.
La couche de base de données contient les tables, les index et les données gérées par chacun des modules.
L'utilisation de l'architecture en couches présente plusieurs avantages :
Les couches sont autonomes : les changements effectués sur une couche n'affectent pas les autres. C'est pratique car nous pouvons augmenter les fonctionnalités d'une couche, par exemple faire en sorte qu'une application qui ne fonctionne que sur les PC fonctionne sur les téléphones et les tablettes, sans avoir à réécrire toute l'application.
Les couches permettent une meilleure personnalisation du système.
Il existe également quelques inconvénients majeurs :
Les couches rendent une application plus difficile à maintenir. Chaque changement nécessite une analyse.
Les couches peuvent affecter les performances des applications car elles créent une surcharge dans l'exécution : chaque couche des niveaux supérieurs doit se connecter à celles des niveaux inférieurs à chaque opération du système.
Quand utiliser l’architecture en couches ?
Voici des situations où elle peut être utile :
Nom de l'exemple | Définition | Exemple concret | Avantages |
Système de contrôle pour les véhicules autonomes | Un système de contrôle pour les véhicules autonomes relie les différentes parties du véhicule à un module de commande qui corrige la direction de la conduite, la vitesse et la trajectoire. |
| Les systèmes de contrôle des voitures autonomes utilisent une architecture à plusieurs niveaux : le même système peut être utilisé si certaines parties de la voiture changent avec le temps, et il peut être utilisé pour différents modèles de voitures. Une seule couche est modifiée. |
Le site web de la banque en ligne | Un site web de banque en ligne est un système qui permet aux clients d’une banque de gérer leurs comptes en utilisant Internet. Ce système est généralement connecté au système central de la banque. | Toutes les banques disposent aujourd'hui d'un système de banque en ligne. | Ces systèmes sont généralement organisés en couches, ainsi si la banque souhaite que le système de banque en ligne ait un aspect différent (pour une nouvelle campagne de promotion de la marque, par exemple), aucun système interne n’a besoin d’être modifié. |
Étude de cas : Résoudre un problème d’entreprise avec l’architecture en couches
Voyons comment une architecture en couches a été utilisée pour résoudre un problème réel.
Amaze est une société de logiciels de gestion de projets. Son produit est vendu dans le monde entier avec un modèle de paiement mensuel par utilisateur, et est largement connu dans la communauté de la gestion de projets pour sa facilité d'utilisation et sa capacité à fonctionner sur de nombreux appareils différents (PC, ordinateurs portables, tablettes, iPhones, iPads et téléphones Android).
Quelle est la problématique ?
Le problème de l'entreprise est très simple : Amaze doit fonctionner sur tous les appareils courants disponibles sur le marché, et être capable de prendre en charge les futurs appareils. Il ne doit y avoir qu'une seule version du logiciel pour tous les appareils. Aucun cas particulier, aucune exception ne sont autorisés.
Donc, pour résumer :
Nous savons que les utilisateurs disposent de différents appareils.
Il ne doit y avoir qu'une seule application logicielle, car l'entreprise souhaite que les coûts de maintenance du logiciel soient faibles.
Lorsqu'un nouvel appareil est lancé, nous ne voulons pas changer l'ensemble du logiciel.
Quelle est la solution ?
Maintenant que nous avons réfléchi au processus, voyons le schéma d'architecture détaillé :
Dans notre cas, la couche des règles de base d'Amaze est essentielle. Cette couche contient des règles qui déterminent le comportement de l'ensemble de l'application, par exemple : « Vous ne pouvez créer un calendrier de projet que si la portée du projet est définie. » L'intelligence du produit se trouve dans cette couche : toutes les fonctionnalités spécifiques issues de décennies d'expérience dans les projets y sont développées. La couche centrale de l'application sera la partie la plus importante du code de l'application.
Essayez vous-même !
Maintenant que vous avez découvert une solution, voyons si vous pouvez appliquer ce que vous avez appris à un autre cas !
Le contexte : Vous êtes architecte logiciel dans une grande compagnie d'assurance de votre pays depuis quatre ans. Votre patron est Carla, la directrice des systèmes d'information (DSI) de l'entreprise. La société possède des bureaux dans 24 villes et emploie plus de 2 100 personnes.
Votre mission : On vous a demandé de développer un système logiciel pour gérer les nouvelles polices d'assurance du personnel de vos clients dans différents secteurs (finance, industrie, technologie, ingénierie, etc.). Chaque secteur a des coutumes et des exigences différentes en matière de gestion des avantages sociaux des employés.
Voici quelques questions clés que vous devriez vous poser :
Comment allez-vous gérer les différentes exigences des secteurs dans un seul et même système ?
Qu'est-ce que les polices de tous les secteurs ont en commun, quels que soient le secteur, le client ou les biens assurés ?
Comment séparer les exigences communes à toutes les industries et les exigences spécifiques à chaque industrie ?
Qui va définir les règles de gestion pour chaque industrie ?
Pouvez-vous créer un schéma d'architecture pour ce contexte commercial ?
En résumé
Modèle d'architecture | Description | Avantages | Inconvénients | Quand l'utiliser |
En couches | Les logiciels fonctionnent en couches qui permettent à tous les composants d'être indépendants les uns des autres. | Encapsulation du matériel, des logiciels et des fonctionnalités. Si une couche est modifiée, les autres couches restent les mêmes. | Pour les petites applications, de nombreuses couches créent un problème de performance et sont très difficiles à maintenir. | Uniquement pour les grandes applications. |
