Architecture logicielle
« Des structures de code permettant d’atteindre des objectifs particuliers dans la structure du code »
Les design Patterns en deux mots
Les Design Patterns sont des structures de code permettant d’atteindre des objectifs particuliers dans la structure du code, et ce indépendamment du langage.
Dans une application, on doit parfois créer l’équivalent d’un adaptateur dans la vie réelle : il faut intégrer un bout de code, mais celui-ci ne « rentre pas bien » dans notre code. Comme dans la vie réelle, il y a des techniques peu pratiques/réutilisables (par exemple souder) et des techniques plus adaptées (utiliser un embout).
Les Design Patterns ne sont que des lignes de code, mais agencées correctement, rendent des codes indépendants et pourtant interconnectés, comme sur la carte mère d’un ordinateur.
Comprendre et appliquer les Design Pattterns augmente la « réparabilité » et l’évolutivité des applications, par le remplacement/l’ajout rapide de parties du code. Les « plugins » dans un logiciel sont un exemple de Design Patterns.
L'architecture logicielle en deux mots
L’architecture logicielle pousse les Design Patterns un cran plus loin en permettant de découper un logiciel en différentes parties complètement indépendantes, souvent hébergées sur des serveurs différents.
L’architecture logicielle, c’est un peu transformer un « programme Dieu » en une fourmilière : chaque partie du programme est indépendante mais toutes sont tournées vers l’objectif commun. On appelle souvent ces différentes parties des « microservices ».
D’autres problématiques interviennent avec l’architecture logicielle :
- Il faut s’assurer que toutes les parties du programme fonctionnent correctement, peuvent échanger facilement des informations, et ne perdent pas d’information en chemin.
- Il faut s’assurer que ces différentes parties peuvent si nécessaire fonctionner en autarcie.
Comprendre et appliquer l’architecture logicielle permet de remplacer rapidement des parties d’un programme, mais également d’en démultiplier certaines parties : par exemple, si un microservice est trop sollicité, on peut le dupliquer. C’est une manœuvre beaucoup plus compliquée à mettre en place avec un programme indivisible.
Dans le schéma microserviciel, un bloc "UI" avec trois sous-blocs représente la partie visuelle de l'application. Reliée par des flèches y arrivant, des blocs "Stateful services" et "Stateless services with relational databases", des applications externes founissant des données.
Dans le schéma traditionnel, une approche par application unique ou d'application "3-Tier", divisée en plusieurs blocs. Cette application est reliée à une unique base de données monolitique. La légende explique : Single app process or 3-Tier approch ; Several modules ; Layered modules.
Découvrir d'autres thématiques
Si nous avons réussi à piquer votre curiosité et que vous souhaitez découvrir d'autres fiches thématiques :