Il y a beaucoup de choses dont j’aurais éventuellement envie de parler, suite à ma visite à Devoxx 2012 (Nota: un jour, c’est trop court ; penser à demander plus l’an prochain 😉 Mais il est une conférence, parmi celles auxquelles j’ai assisté, où les réactions ont été les plus vives ; pendant le speech, au moment des questions, et même après. En effet, notre petit groupe d’internes était très animé sur le chemin de la présentation suivante.
Cette conférence, donnée par Grégory Weinbach (Objet Direct) est basée en grande partie sur la lecture du célèbre ouvrage d’Eric Evans (Domain-Driven Design – 2003). Elle ne visait pas seulement, à mon avis, qu’à exposer les concepts du DDD mais plutôt à bousculer quelques notions confortables (?) d’une manière que j’ai trouvée assez futée.
Démonstration
L’orateur commence par le postulat désormais banal que notre métier d’informaticiens consiste à répondre aux besoins des utilisateurs. Lesquels besoins sont certes souvent complexes, voire mal exprimés. Nous devrions donc nous attacher à ce qu’est l’utilisateur en priorité, afin de comprendre non pas ce que VEUT notre utilisateur mais POURQUOI il le demande ; c’est-à-dire son objectif métier (le domaine).
Selon le DDD, le modèle et le code partagent un langage commun : le modèle objet, qui rassemble les données et le comportement du système d’informations. Afin de l’organiser, ce dernier est organisé en couches dont les dépendances sont hiérarchiques :
On constate dans le schéma ci-dessus que le modèle métier (constitué par les entités du système) est la source centrale des dépendances des autres couches qui s’appuient dessus. Il s’agit de dépendances logiques. Cette couche impose des contraintes aux autres couches, donc, et d’ailleurs la couche de données peut ne se résumer qu’à une transcription (MDE) triviale, mécanique, sous une forme de persistance ou une autre.
Puisqu’il est si important (ce modèle), l’architecte concepteur devra donc se demander COMMENT bien construire le modèle métier. L’approche classique consiste à interroger l’utilisateur afin de déterminer à quels concepts son métier peut se réduire, des entités modélisables. Ici, l’on se représente tout à fait le dictionnaire de données, dans les règles de l’art de la franchouillarde (sans offense) méthode Merise, et on aboutit à un diagramme de classes tentaculaire le plus complet possible. Pour y arriver, il faut découvrir quelles sont les abstractions des concepts métiers pour CHAQUE utilisateur. On apprendra plus loin, dans un dictionnaire philosophique datant de plusieurs siècles, que l’abstraction permet de se concentrer sur certaines propriétés et non l’ensemble. Le modèle est donc contextuel, il s’agit d’un point de vue. Certaines informations seront communes à toutes les projections du concept, mais en général très peu. Pour passer d’un modèle à l’autre, on aura donc recours le cas échéant à des transcodifications.
En fait, le DDD constate que la pression des dépendances logiques s’applique d’abord dans le sens de la descente (top-down). En particulier, j’imagine, dans un environnement de production tendu (le fameux “time to market”). L’idée, si j’ai bien compris, est que si le besoin est simple, l’interface (la perspective) de l’utilisateur doit aussi être simple ; et il n’y a donc aucune raison que le modèle métier ne le soit pas quant à lui. Le Domaine du DDD ne se rapportera qu’au seul contexte du use case :
Pour modéliser un concept, il conviendrait donc de choisir le contexte afin de s’intéresser au coeur du domaine… le client (en fait, l’acteur) ! Or, en DDD, c’est l’usage via le logiciel qui détermine le modèle métier. Celui-ci reste une projection de la réalité et n’a en aucune manière vocation à être exhaustif ; ce qui est considéré comme improductif (c’est moi qui rajoute). On travaille donc sur la base de cas d’utilisation (les intéractions), ce qui aboutit à une organisation différente. Le vocabulaire reste pourtant le même, mais le modèle n’est pas issu des besoins logiciels. OMG !
Premières critiques
Modèle contextuel, voire partiel ; transcodification…
En DDD, on peut avoir plusieurs modèles qui cohabitent dans une application. Ceux-ci peuvent être redondants (OMFG !) ; et, pire que tout, on ne s’inquiète pas de la façon dont les entités seraient au final le mieux persistées (WTF !!!). Selon moi, on devra par conséquent probablement fournir un effort caché futur (et cacher les coûts au client fort chéri, c’est mal), lorsqu’il s’avèrera nécessaire de réconcillier les modèles pour des besoins transversaux : “Il conviendra de communiquer sur ce point ; cet effort sera traité alors en tant que nouveau use case (ETL)” m’a-t-on répondu en substance.
L’un des participants s’est violemment élevé contre le fait de ne pas s’attacher à consolider la couche de données. Selon lui, les données constituent la valeur la plus importante de l’entreprise. Peu important la méthode de collecte ou de saisie. Les logiciels passent mais les données restent, en somme. Petit flottement ; je comprends soudain pourquoi Grégory Weinbach a gardé tant de temps pour les questions… Les réactions sont vives, c’est bien normal et c’est bon signe : c’est la preuve qu’un point sensible est touché.
Bon, après j’ai pas tout compris aux interventions du public, j’avoue. Il fut question de DSL (j’accroche à peu près), de modèles adaptatifs (à éviter, selon l’orateur “le besoin virtuel n’est pas prouvé” – j’attends une autre présentation). Bref, passons.
Prise de recul
Parlons franchement. Une grande part de la valeur de l’architecte logiciel et de sa légitimité vient de sa capacité à produire de bons gros diagrammes de classes “bien formé”, de préférence en UML. Non ? La fierté du concepteur, c’est sa capacité à anticiper toutes les évolutions possibles et imaginables. Ce qui n’arrive JAMAIS, nous le savons bien. Il y a donc là matière à un débat sans fin, probablement teinté de mauvaise foi et de personnalisation à outrance.
Mais, à bien y réfléchir, qu’est-ce qu’une architecture SOA ? L’architecture SOA consiste à mettre en relation des systèmes potentiellement hétérogènes au travers de contrats et de protocoles communs… des transcodifications ? Si les outils du TDD peuvent permettre d’adresser cette complexité, nous devons les envisager pour résoudre ce genre de problématiques. Pensez aussi aux systèmes concurrents que vous avez peut-être eu à fusionner au prix de longs (et coûteux) efforts en un seul système centralisé… Quels gains, en termes d’objectifs métier, ont-ils été réalisés in fine, pour l’utilisateur final ?..
Je vous invite à donner votre avis et à partager vos témoignages sur ces questions ouvertes. Merci.
