Commentaires sur : Eric Evans, Domain Driven Design au Paris JUG

Par : Think Before Coding

Think Before Coding — Tue, 16 Jun 2009 22:13:17 +0000

Met Eric Evans at ParisJug…

The ParisJug organized a DDD event yesterday in Paris presented by Eric Evans, the author of Domain Driven Design himself. He’d come in France ten years ago, but never made a presentation about Domain Driven Design here yet. Thanks to Antonio and…

Par : jeremie

jeremie — Tue, 16 Jun 2009 20:59:06 +0000

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.

Par : slimtebourbi

slimtebourbi — Tue, 16 Jun 2009 20:51:54 +0000

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.

Par : Nicolas Martignole

Nicolas Martignole — Tue, 16 Jun 2009 15:44:08 +0000

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.

Par : alexdp

alexdp — Tue, 16 Jun 2009 13:31:48 +0000

Y’en a marre. C’est décidé, je vais lire le livre pour me faire un avis fondé!

Par : alexdp

alexdp — Tue, 16 Jun 2009 12:48:11 +0000

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.