Architecture logicielle : l’indispensable à savoir

Le concept d’architecture logicielle est aussi indispensable qu’ignoré par la plupart des développeurs. Ceux qui s’y intéressent, même un petit peu, ont un énorme avantage sur les autres. Sans aucun effort investi dans le sujet, ton système est condamné à devenir impraticable. Abordons les bases pour éviter ça.

Concept

Il suffit de prononcer le mot « architecture » pour intimider et faire fuir énormément de développeurs. Aujourd’hui, je vais te prouver qu’il n’y a rien d’impressionnant dans tout ça.

L’architecture logicielle c’est simplement l’organisation dans laquelle les différents composants de ton application vont être séparés et vont communiquer entre eux.

Dans certaines boites, quand les enjeux sont assez importants, tu vas avoir une personne dédiée à cette question. Une personne qui va en faire une affaire personnelle. Une personne au poste d’architecte logicielle.

Mais c’est en fait assez rare d’avoir quelqu’un comme ça.

Alors qu’est-ce qui se passe dans la vraie vie sans architecte ? La plupart du temps, ça devient l’affaire de tous les développeurs d’une équipe. Et par paresse ou simple effet du témoin, tout le monde ignore la question.

Le produit est développé sans vision, au plus vite, le condamnant à la plus grande des malédictions.

Utilité

Le but ultime de l’architecture logicielle c’est de faciliter le développement, l’évolution, le déploiement et la maintenance d’un système.

Minimiser le temps et le coût d’intervention. Maximiser et maintenir la productivité des développeurs face aux changements. Rendre tout ajout ou modification simple et rapide.

Si j’insiste autant sur ce point, c’est pas pour rien.

Une bonne architecture logicielle permet évidemment de bien faire fonctionner ton application. Mais ce n’est pas la raison principale de son existence. Ce n’est pas la raison principale pour laquelle on met autant d’effort la-dedans.

Je veux dire, tu peux très bien avoir une architecture logicielle inexistante -ou très mauvaise- et avoir un produit qui marche parfaitement.

Dans le vrai monde réel de la réalité véritable, c’est ce qui se passe la plupart du temps. Mais le prix à payer c’est qu’au moment de faire évoluer ce produit, c’est un véritable cauchemar. Et ce sont les développeurs responsables qui en payent le prix.

En proposant quelques règles de base à ton équipe, tu peux facilement rendre ta vie -et celle de tes collègues- plus agréable.

Portée

L’architecture logicielle est fréquemment confondue avec un paquet d’autres concepts et détails qui n’ont rien à foutre ici.

Une architecture n’est pas le choix d’un framework, d’un langage et/ou d’une base de données. Une bonne architecture permet de rendre ses choix secondaires et interchangeables jusqu’au dernier moment.

Une bonne architecture fait ressortir le cœur du problème à résoudre, pas les détails d’implémentation.

Il y a beaucoup de types et de philosophies différents autour de l’architecture logicielle. Je pourrais faire un article entier qui les listes. Le comment du pourquoi plus l’infini.

Mais ton temps est précieux, je vais donc me concentrer seulement sur celle que je connais bien et que j’ai déjà pratiqué plusieurs fois.

La très connue « Clean Architecture » de Robert C. Martin.

Cette façon de faire l’architecture a fait des merveilles là où je l’ai vue. À force, je suis devenu un fanatique de cette façon de faire. Ça fonctionne, c’est agréable à utiliser et c’est absolument magnifique à faire évoluer.

Deux fondamentaux

D’abord, il faut comprendre que tout ce que je vais aborder à partir de maintenant est régi par les principes SOLID. Si tu ne les connais pas, sache qu’ils sont entièrement expliqués et disséqués dans ce bouquin.

Isolation par couches

Il faut commencer par un partitionnement strict et bien isoler des différentes couches qui font ton application.

L’architecture propre est entièrement définie par différentes couches indépendante. On part de la couche qui concerne les détails pour aller jusqu’à la couche la plus critique. De l’interface utilisateur au cœur des règles métier.

Il est important ici de respecter le principe de responsabilité unique des principes SOLID.

Pour te donner une vision globale, regardons le schéma officiel de la clean architecture.

Continuons avec le second fondamental pour déchiffrer tous ces hiéroglyphes.

Règle de dépendance

C’est une règle qui spécifie la relation entre les couches de ton système. Un composant de haut niveau ne doit rien savoir d’un composant de plus bas niveau. Aucune dépendance et/ou mention de la couche plus basse doit être introduit dans celle du dessus.

Faisons un petit zoom sur le schéma de la clean architecture, pour mieux comprendre le charabia du paragraphe précédent.

Au milieu, on trouve la couche la plus importante de ton application : les règles métiers !

Quelles sont les règles les plus critiques, qui ont le plus d’impact, et qui définissent le cœur de ton application ? C’est la logique qui doit se trouver dans les règles métiers.

Fais-en un composant, complètement séparé du reste, qui ne dépend de rien n’y personne. Un regroupement de méthodes et de fonctions qui pourraient fonctionner tout seul. C’est le plus haut niveau.

Ce qui doit le moins changer, ce qui est doit être le plus protégé, au centre de tout.

La couche juste en dessous c’est les cas d’utilisations. La façon dont les règles métiers vont être utilisées. C’est à dire, dans quel ordre et dans quel sens le flow de la donnée va être utilisé.

À contrario avec les règles métiers, les cas d’utilisations ont une dépendance : justement les règles métiers.

Cependant comme les règles métiers, les cas d’utilisation ne connaissent pas l’existence des couches qui dépendent d’elle. Et la même logique se répète de la couche la plus générale de l’application à la plus spécifique.

Les détails dépendent de tout, le cœur ne dépend de rien.

Ces deux grands fondamentaux te permettent déjà d’avoir une idée de ce qu’il faudrait mettre en place en amont pour une bonne architecture logicielle. Malheureusement je n’ai pas trouvé le moyen de continuer cet article sans t’en faire une lecture de quatre heures.

Aller plus loin

J’ai souffert pour te parler d’un sujet aussi dense et aussi complexe, dans un format aussi court. Pour te permettre de comprendre l’utilité et le concept global, cet article est largement suffisant.

Si tu veux maîtriser ces notions et les utiliser dans ton travail, il faut que tu ailles plus loin.

Tu l’as compris, ma grosse recommendation du jour est le livre Architecture Logicielle Propre de Robert C. Martin. Si tu n’aimes pas les traductions françaises, sache que la version originale en anglais est disponible aussi (elle est moins cher en plus).

Ce livre part du principe que tu es un développeur qui veut évoluer dans le futur et avoir une vision plus globale des choses. Il débute donc du code que tu connais déjà. Il continue en te présentant les principes de programmation SOLID en détail. Puis il va progressivement aborder chacun des fondamentaux de l’architecture et les liens qu’ils ont entre eux.

Tu t’en doutes, il y’a plus que les deux fondamentaux dont je t’ai parlé.

Puis il finit par appliquer tout ce que tu appris avec une étude de cas qui rend très concrète toutes les notions abordées.

Tu n’as besoin de connaitre un langage en particulier pour le lire. De petites bases en programmation-objet (interface et abstraction simples) sont préférables. C’est largement compréhensible sur le tas.

J’ai adoré ce bouquin.

J’ai passé la moitié du temps à hocher de la tête en mode « épiphanie du dev » en le lisant. J’en suis sorti avec une vision différente et surtout plus globale sur le métier. Rien que pour ça, je pense qu’il devrait être lu par n’importe quel développeur qui cherche à améliorer ses compétences.

Épilogue

La qualité de ton application commence par sa base. La base est son architecture. Ce travail en amont à un impact majeur sur les cycles de mise à jour et de déploiement de ton application dans le futur. Comprendre et utiliser ces notions aura également un impact majeur sur ta carrière.