Il est rare d'avoir un système logiciel de pur calcul, c'est-à-dire qui ne doive pas "retenir" quelque chose au fur et à mesure du temps. C'est toute la question de l'état du système.
La gestion de l'état est le premier rôle d'une architecture, puisque c'est de lui et de sa représentation que naissent quasi tous les problèmes logiciels majeurs (concurrence, évolution, performance, etc.). Il existe des solutions différentes, on peut par exemple citer les deux extrêmes suivantes:
L’état encapsulé
Dans ce style, un module logiciel est responsable de son état. Lui seul a l'autorisation d'y accéder directement. Tout autre module du logiciel devra passer par ses services s'il veut connaître ou modifier quoi que ce soit sur cette partie de l'état du système.
👉 Typique des abstract data types (ADT) ou des microservices qui gèrent leur propre persistence.
L'état public partagé
Ici, l'état du système est représenté par un modèle de données global, dont la représentation est visible de tous. S'il faut en gouverner les accès, certainement en écriture, il est fréquent de laisser modules logiciels et humains accéder à l'information dont ils ont besoin sans se soucier des autres (si les requis de sécurité le permettent).
👉 Typique des bases de données relationnelles ou des systèmes de fichiers.
Similitudes historiques...
Pris à la lettre, ces styles architecturaux semblent diamétralement opposés. Le premier cache l'état, le second l'expose au grand jour. Les modules du premier gèrent leur état, alors que cette notion de responsabilité est plus floue dans le second.
Ce que l'on sait moins, c'est qu'ils sont tous les deux le résultat d'une même recherche d' "indépendance" lors de la crise du logiciel des années 60s.
1️⃣ On doit l'information hiding à David Parnas. Il veut éviter au développeur d'un module d'utiliser la représentation de l'état choisie par le développeur d'un autre module, et qu'ils doivent se synchroniser à chaque changement pour ne pas tout casser.
2️⃣ On doit la notion de modèle de données à Edgar F. Codd. Il cherche à éviter au développeur d'un module de devoir réécrire tout son programme s'il change la manière dont les données sont stockées sur disque ou représentées en mémoire.
... mais différence d'approche
Deux approches d'un même problème, mais des choix différents dans l'espace de complexité architecturale que j'évoquais récemment.
Comme le veut l'adage, choisir, c'est sacrifier :
1️⃣ Cacher la représentation de l'état revient à cacher en partie l'information sur l'état [1]. Un nouveau requis peut nécessiter de revoir le module et son interface, de dupliquer l'information dans un autre module, ou d'introduire transferts et synchronisations de données complexes entre modules.
2️⃣ A l'opposé, le modèle relationnel expose à dessein l'information sur l'état du système dans une forme simple, transparente, générique, et stable (les relations, aka tables). Mais il ne sait éviter l'inévitable : un modèle de données capture la compréhension du domaine à un instant donné, au travers entre autres d'un choix vocabulaire. Or, la compréhension du domaine évolue dans le temps, et les changements inéluctables du modèle de données imposent des changements des modules qui l'utilisent [2].
No free lunch.
#SoftwareEngineering #Architecture #Databases
Cette distinction entre information sur l'état et représentation de l'état est essentielle. Elle est malheureusement rarement discutée. ↩︎
Les vues étaient envisagées par Codd comme mécanisme majeur d'évolution. Mais leur limitations théoriques, et pratiques dans les produits SQL, le rendent souvent inadéquat. ↩︎