Cher lecteur bonjour. Lorsque tu liras ces quelques lignes, je serai entrain de dormir. En effet, prévu de longue date, ce mardi 16 juin est une journée off, ce qui m’arrange bien par ailleurs.
Alors tu t’es inscrit pour la soirée Domain-Driven-Design organisée par le Paris JUG. Tu es arrivé à l’heure, c’est bien. Saches que tu étais 111 personnes ce soir. Qu’il y avait 168 inscrits. Et note cher lecteur que nous avons mobilisé ces 168 personnes en 4 jours. Merci Twitter, merci aux blogs qui ont fait suivre l’information (SFEIR, Xebia, Zenika) et surtour un grand merci à l’EPITA qui nous a reçu.
Antonio a eu vent de la venue d’Eric mardi dernier. Nous en avons discuté mardi soir entre l’équipe, le canal historique (Antonio, David et Zouher) et les dissidents, dit « la Crew » à savoir Tanguy, Charles, José et moi-même. Et motivé comme pas deux, nous voilà engagé pour trouver une salle pour 180 personnes, ce qui fut possible grâce à Tanguy Bayard de SFEIR et Nicolas le Coz de Xebia, ancien de l’EPITA.
Arrivé tôt, me voilà déguisé en videur, pendant que Tanguy colle les affiches partout dans l’EPITA pour guider nos juggeurs vers l’amphi A04. Quand je dis déguisé en videur, je me retrouve à t’accueillir, toi cher Jugeur qui est venu, pas comme les 58 qui n’ont pas pu venir. Cela me permet aussi de démontrer un certain talent à reconnaître les gens, avec un « Salut Laurent » ou un « Salut Claire, Salut Claude » du plus belle effet. C’est ça d’être un bloggeur, à force on connait beaucoup de monde, même si le monde ne vous connaît pas en retour. Le déguisement de videur sans doute… Bref passons.
Début
La séance commence. Soyons un peu plus sérieux pour parler contenu. Eric Evans nous présente ce soir Domain Driven Design. L’objectif de la présentation sera de présenter la conception pilotée par le domaine. Aucuns frameworks, pas de mots techniques, du bon sens comme dit mon voisin du Coder’s Breakfast sur Twitter. Mais du bon sens sacrément intelligent, ce qui vaut le coup de passer 2 heures avec Eric.
Passons rapidement sur le style. C’est vrai qu’il a un côté un peu mou, ce qui rend un peu long la présentation. C’est le fond qui est intéressant. A l’issue de la présentation je suis partagé. Je ne peux pas dire que j’ai été complètement emballé, ce serait faux. J’ai entendu quelques concepts intéressants qui me donnent envie d’aller plus loin.
Eric a écrit un livre de 560 pages appelé « Domain Driven Design, Tackling Complexity in the Heart of Software« . La présentation dure 2 heures. L’article du Touilleur doit faire environ 1500 caractères… Bref tu l’auras compris cher lecteur, il sera difficile de te résumer ici tout ce que j’ai vu. Allez bonne soirée à demain.
Non soyons sérieux… Voici ce que j’ai entendu et que je dois te raconter. La définition du « domaine » pour commencer, est la sphère de connaissance qui influence notre activité d’après Eric. Tout d’abord il explique qu’il faut se faire aider et encadrer d’expert métier pour comprendre le métier, et donc le modèle de votre logiciel.
Il débute la présentation par l’exemple d’un Cargo, qui transporte des containeurs de Hong-Kong vers San Francisco. Il nous demande : comment modéliser ce transport de marchandise ?
La première approche classique, avec une Entité Cargo, est de stocker en base une ligne par parcours. Ce qui l’embête dans cette approche c’est que le Business n’a pas forcément envie d’entendre parler de base de données. Il dit même qu’en travaillant de la sorte, un jour votre MOA débarque avec un schéma de base de données au lieu de vous expliquer le besoin… pas faux.
Soit un Cargo qui a une relation de n « Stop ». Chaque stop a une date de chargement et de déchargement. Ok ce modèle fonctionne. Prenons ensuite un Cargo qui a une Leg, ou parcours. Ce parcours a un point de départ et un point d’arrivée. Cela marche aussi.
Dès le départ, il explique que le modèle dans la conception Objet est une projection déformée de la réalité. Pour illustrer son propos, il prend l’exemple d’une carte du monde. On voit dans le premier slide une carte Chinoise. La Chine est représentée au milieu, le reste autour. Ensuite une projection de Mercator avec les USA en plein milieu. Le message passe : quelque soit le vrai domaine, le domaine objet est une projection qui apporte nécessairement une déformation.
Pour lui, un modèle est donc un système d’abstractions qui peut être utilisé pour résoudre un problème.
Ensuite vient l’utilisabilité. Un modèle n’a de sens que s’il est possible de l’utiliser. Il nous explique qu’il est inutile de tenter de créer un modèle exhaustif, qui sera forcément trop compliqué. Il nous conseille de travailler par itération, et la suite de la présentation va donc s’axer sur la technique de conception de ce modèle.
Tout d’abord posez vous cette question « Qu’est-ce qui est le plus utile ?« . Prenez quelques scénarii réels de votre client pour piloter votre conception. C’est ce qu’il va faire dans la suite de sa démonstration.
Alors vous avez conçu votre Cargo et vos routes, votre bateau est parti de Hong-Kong vers San Francisco. Maintenant prenons le cas où le client décide de changer de destination alors que le bateau est au milieu du Pacifique. Comment votre modèle va-t-il gérer cela ? Il s’avère que le modèle construit sur les Legs (les routes) sera le plus adapté au problème du reroutage là où un modèle conçu avec des « Stops » ne sera pas adapté au changement facile.
Eric Evans en profite alors pour nous parler de ce qu’il appelle « ubiquitous language ». Lors de la conception objet, il nous demande d’utiliser un langage qui sera compris par tout le monde. Pour illustrer cela, il dit : « si demain vous démarrez un projet avec des Indiens, vous êtes d’accord pour parler et écrire uniquement en anglais non ? alors faites de même pour le design de votre modèle : utilisez un langage universel ».
Après avoir vu différents diagrammes, il complexifie encore la chose en ajoutant une troisième demande du métier : « Je veux la route la moins chère ou la route la plus rapide pour mon bateau ». Il reprend le modèle pour nous montrer que rapidement, ce modèle ne sera pas capable de résoudre cette demande. Cela lui permet alors de nous faire prendre conscience de quelque chose : un modèle n’a de sens qu’avec le Contexte qui l’utilise. Le calcul du « plus rapide » ou du « moins cher » se modélise avec des Arcs, des Routes, du calcul par graphe. Rien à voir avec le modèle du transport, un simple modèle père-enfants relativement simple.
Il nous demande alors d’isoler nos modèles selon le contexte, afin de nous garantir de la surcomplexité. De sa propre expérience, la tentation est grande de n’utiliser qu’un seul modèle pour faire tout, ce qui conduit à une architecture pilotée par la technique, au lieu d’une architecture métier.
Le prérequis pour un modèle objet complexe est donc la disponibilité d’experts métiers, une écriture par itération, une définition des frontières du modèle très claire et une définition du contexte pour l’utilisation de ce modèle.
Lors de la séance des questions réponses, il dira qu’en effet le terme « Business Driven Design » est aussi une bonne représentation de ses idées.
Conclusion
Nous restons un peu sur notre faim. D’un point de vue conception, je vous avoue qu’il est très difficile de te retranscrire ici ce que j’ai entendu. A titre personnel j’ai appris ce soir à voir le modèle à sa juste place, avec une prise de conscience du contexte. Ne pas chercher à être exhaustif, à créer des cas d’utilisations qui n’existent pas. Attention à ne pas aussi faire de la modélisation pilotée par la technique. Vous devez être en mesure d’exprimer toutes vos contraintes avec le code.
Il cite pour terminer le framework Qi4J dont Florent Ramière de Jaxio et Sébastien Letélié m’ont déjà parlé. Quand 2 geeks vous parlent d’un sujet, il faut se renseigner. Voir à ce sujet les articles écrits par Sébastien comme celui-ci par exemple.
Off
La soirée se termine, tu rentres chez toi cher lecteur. Cela me permet de discuter avec des têtes connues ou pas, de rencontrer Patrice Lamarque d’eXo Platform et de discuter de la fusion JBoss Portal / eXo Portal, de parler avec Didier Girard d’une idée pour cette été, pour enfin terminer dans une Brasserie avec les Juggeurs, quelques têtes connues comme Eric « Bob » Mignot et Eric Evans.
Il est temps de prendre mon RER A garé en double file, et d’aller dormir. A bientôt, à jeudi soir pour les Scrumistes et au 7 juillet pour les Juggeurs.
0 no like
Mouaih mouaih mouaih. C’est un peu la vérité de la palice tout ça. Un modèle non anémique. Des objets qui ont des comportements. C’est bien ça mais par définition, un objet n’est-il pas la fusion d’un état et d’un comportement? Bref, je ne vais pas plus loin car je n’ai pas lu l’ouvrage de référence et me suis contenté d’une (vraie) lecture de Domain Design Quickly sur InfoQ. Pour autant, c’est ce que j’essaie de faire depuis des années dans mon projet open source. Il n’y aurait donc de révolution que pour ceux qui ont été nourris exclusivement à la couche service bourrée de transaction scripts et aux entités creuses de base de données. Et là encore, c’est finalement discutable puisqu’obtenir un modèle métier de qualité n’est pas chose simple, surtout quand on veut faire du DDD. Il n’est pas rare de devoir refactorer à coup de hache les classes modélisant des entités métier avec un grain trop gros et donc trop de resposabilités, trop de code et trop de compléxité.
PS : le coup du Cargo d’Eric est un projet d’exemple qu’il a publié sur le web ou je me trompe? Et bien si c’est celui là, je vous invite à ouvrir le code. Au hasard, j’ai pris une classe. Et bien on ne peu pas dire que le survol du code m’a permis de comprendre le rôle de l’entité métier. Ce que je me suis finalement dit, c’est : si je modifie du code là, quels seront les impacts sur le reste du domaine? Le DDD montrerait donc la complexité du métier sans pour autant la tâcler facilement. Je reste dubitatif.
Y’en a marre. C’est décidé, je vais lire le livre pour me faire un avis fondé!
J’ai regardé le livre. 560 pages, et on retrouve l’exemple du Cargo. C’est très conceptuel, pas forcément simple à expliquer, ou peut-être pas si révolutionnaire ? Je vous conseille de jeter un oeil sur QI4J pour appréhender une vraie implémentation.
Le plus important c’est la prise en compte de l’importance du domaine finalement, et le respect du client, de la valeur métier.
Je vois malheureusement que la prestation de Mr Evans n’as pas été assez convaincante, mais je pense que cela ne doit en aucun cas diminué l’importance de l’approche qu’il defend. De plus, je ne me rappelle pas l’avoir entendu dire qu’il presenter quelque chose de revotutionnaire! Sa seule innovation est peut etre les noms des designs pattern qu’il a decrit dans son excellent livre (que je t’invite vivement a lire Nicolas) et qui en partie etait cités par Martin Fowler ou d’autres bien avant lui (avant d’atteindre leur popularité actuelle). En ce qui concerne les exemples vous pouvez en trouver de trés bons ici http://sourceforge.net/projects/timeandmoney ou encore ici http://dddsample.sourceforge.net/ (existe aussi avec QI4J). Enfin, et pour QI4J et meme s’il est trés inspiré par les notions de DDD, il essaye surtout de mettre en oeuvre un nouveau paradigme le Composite Oriented Programming.
C’est effectivement pas évident de sentir ce qui est vraiment important dans tout cela…
L’important c’est le travail de compréhension du domain avec les experts, et la création du language qui va servir dans les raisonnements et qui doit aider à la compréhension.
C’est la que repose la complexité intrinseque d’un projet informatique. Comprendre le métier, comprendre que dans un métier, il n’y a pas d’erreurs, mais des cas plus rare que d’autres et que c’est la façon dont les choses fonctionnent.
Que les mêmes choses prennent des formes différentes dans un même domaine (bounded context) et qu’il faut souvent modéliser les mêmes choses de plusieurs façon dans une même application.
Que tout ceci a un but pour l’entreprise dans laquelle on travail, c’est son métier, et que c’est ce qui fait sa valeur, ce qui doit être traité avec le plus d’attention.
Les problématiques techniques viennent ensuite et sont des détails d’implémentation vis à vis de la tache à accomplir.
Mais comme indiqué pendant la conférence, un point à ne pas oublier est que tout cela n’est utile que dans le cas ou la complexité du domaine est très supérieur à la complexité technique.
Inutile d’essayer d’appliquer DDD à un forum ou à une petite application n’ayant qu’un nombre réduit d’interactions.
L’application des Cargos est un bon exemple. Il faut faire les itinéraires, savoir où sont les bateaux, organiser les chargements déchargements, gérer le stockage, assurer le suivi des containers auprès des clients, le transport peut prendre du retard, il faut le gérer, les clients peuvent changer de destination en cours de trajet, il peut y avoir des containers chargés sur le mauvais transport qu’il faudra rerouter individullement, la gestion des taxes, des timezones, des monaies, des contraintes sur le types de matérieaux qu’il peuvent transporter… et encore des milliers des choses que les milliers de personnes impliquées dans ce métier font tous les jours sans y penser.
DDD propose de commencer par créer le code qui fait tourner tout ca de façon simple et directe indépendement de tout détail technique pour que ces détails techniques ne puissent pas ensuite empecher l’évolution de l’application pour s’adapter encore mieux aux demandes du métier.
Désolé pour la longueur du commentaire, j’espere juste que ca permetra de mieux comprendre pourquoi Eric Evans n’avait pas beaucoup envie de parler de Framework et de patterns objet.