Sur invitation de Zenika, je participe cette semaine à la formation Domain Driven Design, animée par Eric Evans. Avant que je n’oublie, Eric effectue une présentation de DDD ce mercredi 17 février à 19h00. Rendez-vous au Club Confair, métro Notre-Dame de Lorette ou Le Peletier. Les inscriptions se font via le site de Zenika.
Eric Evans est l’auteur du livre « Tackling Complexity in the Heart of Software« , un livre de 2004 qu’un bon nombre d’architecte ont lu. Il débute sa carrière dans les années 90 avec SmallTalk, un langage dont il reste un fervent défenseur. La formation s’adresse autant à des développeurs Java, qu’à des développeurs .NET. Dans les années 90, les usines logicielles et la modélisation UML étaient les promesses qu’en 2000, les logiciels seraient générés, pas forcément modélisés. En 2001, avec l’arrivée de l’architecture J2EE, il y eu une mode de l’architecture très technique. Lorsqu’il dit cela, je pense en effet qu’il y a eu un eldorado des architectures techniques, construites et vendues par des vendeurs de machine, en dépit parfois du bon sens et des besoins des clients.
Un domaine, un modèle, les mots doivent être clairement définis. Un domaine est une sphère de connaissances, d’influence et d’activité. Le plus compliqué parfois est de comprendre le modèle lui-même. DDD (Domain Driven Design) n’est pas une nouvelle méthode mais une philosophie d’architecture. Il s’agit d’un ensemble de principes, qui doivent vous aider à construire une architecture complète. Faire du « DDD » c’est finalement parler avec un ensemble de Patterns, c’est avoir un nouveau vocabulaire pour travailler avec d’autres développeurs, d’autres architectes. Connaître DDD c’est gagner du temps. Lorsque vous parlerez de « Value Object », votre interlocuteur comprendra de quoi vous parlez.
La formation nous permet d’acquérir de nouveaux outils et un nouveau vocabulaire. C’est un framework conceptuel.
Eric Evans présente ensuite quelques notions déjà abordées lors de sa présentation sur DDD en juin dernier au Paris JUG. Mais ce fut intéressant de revoir et d’entendre une version plus détaillée de cette première partie. Par un exemple mal fait, il nous montre quelques mauvaises pratiques d’architecture.
Ecoutez un peu cela et dîtes-moi si vous êtes d’accord : il prend l’exemple d’un client qui vous demande de modéliser un système d’envoi de colis. Quelques minutes plus tard, vous êtes entrain de parler Hibernate, Spring et GWT… Stop ! Dès lors que votre solution d’architecture expose d’abord les technologies, vous êtes entrain de vous planter. Il est primordial de travailler d’abord avec les personnes du métier, d’avoir accès aux clients, de rencontrer des utilisateurs, avant de décider des choix techniques. C’est vital pour la qualité d’une Architecture.
Nous poursuivons dans la journée avec un atelier de refactoring de code. La chose présentée devant nous semble avoir été développée en 1998 du temps des premières architectures Java client-serveur. Le pire c’est que le code fonctionne. Mais la lecture et la compréhension du code me rappelle quelques souvenirs. J’en ai vu du code mal écrit. Après avoir regardé un peu le code, nous travaillons sur des tableaux blancs à plusieurs. En fait, il explique que la modélisation se fait souvent à plusieurs. Pourquoi le développement ne se fait pas à plusieurs aussi ?. C’est la pratique du Pair Programming, que nous avons utilisé tout au long de la journée pour nettoyer cette application.
Afin de nous amener à revoir cette application, Eric nous fait travailler sur différents ateliers, où le Modèle prend toute son importance et sa valeur. Oubliez vos machins UML et autre MDA. Nous parlons ici simplement d’un schéma sur un tableau blanc, quelque chose que vous allez refaire 243 fois, que votre client doit comprendre. Ce qui apparaît rapidement, c’est notre faiblesse à tous à comprendre et à restituer le modèle. Je m’aperçois que nous sommes très formatés « programmation objet« . Nos discussions parlent de Classes et s’éloignent en fait du besoin de base du client. Alors j’aurai appris à être moins « Orienté Objet » et bien plus « Orienté vers mon client que j’écoute ».
Un modèle en informatique doit servir pour un usage particulier. L’image qu’Eric utilise est une carte du monde. Celle-ci est une projection d’un objet réel. Comme vous le savez, la projection d’une sphère entraîne des erreurs. Mais la projection de Mercator par exemple permet de calculer des caps géographiques, et elle est donc adaptée pour les navigateurs. Par contre, elle représente le Groenland comme étant aussi gros que les USA, elle n’est donc pas adapté pour montrer la taille des continents.
Votre modèle métier est une projection du modèle client. C’est une abstraction travaillée avec les clients, qui fait quelques sacrifices, mais qui ne doit pas être trop guidée par vos choix techniques. Il conseille aussi de dénormaliser votre modèle. Lorsqu’un problème est traité de 2 manières différentes, pourquoi ne pas avoir plusieurs objets pour représenter vos objets réels ? Pourquoi aussi s’handicaper et alourdir votre logiciel, si certains champs n’ont aucunes utilités ? Pensez-y la prochaine fois que vous ferez « new class ».
Un modèle n’est jamais meilleur qu’un autre. Il n’y a pas de bons modèles. Prenez un marteau et une scie. Si je vous demande de scier la table, quel outil utilisez vous ? Celui qui est adapté ! Un modèle doit être utile et donc il doit être particulièrement bien pensé pour s’éviter du code inutile. Ce sera d’ailleurs l’exercice plus tard dans la journée : descendre des méthodes dans un objet Inventory.
Il insiste ensuite sur l’importance du vocabulaire, du langage. Dans votre secteur, vous devez tenir un Thésaurus, un document qui liste les mots de votre domaine. Ce document doit être discuté avec les clients, afin de s’assurer de la bonne compréhension de chacun des objets du domaine. Pensez aussi à parler du contexte dans lequel les mots sont utilisés. Une dette pour un client est une créance ?
Enfin pour nous faire travailler, Eric nous demande de lister les pré-conditions et les post-conditiosn d’une méthode. Cet exercice très simple nous amène à ajouter des tests, à revoir une partie du code. Il apparaît alors que le modèle technique est bon, mais il souffre d’une dette de compréhension par rapport au client. Eric nous demande d’implémenter un système pour revoir les routes de nos Cargos. Et là nous nous rendons compte que le modèle technique est franchement inadapté. La journée s’est poursuivie en travaillant à plusieurs sur des ateliers bien écrits.
Voilà pour cette première journée, la suite au prochain numéro.
0 no like
Ce que j’aime bien dans le Domain Driven Design, c’est que le mot informatique prend tout son sens (contrairement au mot ‘Computer science’).
On revient au sens premier d’automatisation de l’information : on veut créer un modèle pour gérer automatiquement l’information des utilisateurs… les technologies utilisées ne sont qu’un détail d’implémentation.
DDD, ça fait un moment qu\’on en parle sur InfoQ, enfin j\’ai l\’impression que ce mouvement entre dans l\’esprit des gens en France.
Je suis d\’accord avec \ »thinkbeforecoding\ » ça permet de remettre au centre le coté information, et l\’information qui compte pour le client.
Aussi, l\’utilisation du modèle en DDD me fait vaguement penser à un pattern en architecture : NakedObjects.
Alors, est ce que cette formation de 4 jours fait de toi, un meilleur ingénieur/architecte/CDP ?
Qu’est ce que cela a changé dans ta manière de travailler ?
Certainement un meilleur architecte, avec de nouveaux concepts, un nouveau vocabulaire et une démarche novatrice. J’aurai l’occasion d’en parler dans quelques semaines. Donc oui, je pense que cette formation changera ma manière de travailler. L’essentiel de mon travail en ce moment est de conseiller des entreprises et des projets dans les domaines de l’architecture, de la finance et du Web. Le Domain Driven Design apporte une vision stratégique sur les projets informatiques très intéressante. Il y a quelques parties peut-être trop « conceptuel » mais l’ensemble est intéressant à connaître.