Résumé de la présentation Domain Driven Design par Eric Evans organisée par Zenika
La soirée a commencé par une présentation du DDD User Group parisien avec Jérémie Grodziski et Grégory Weinbach ainsi que le prochain lancement du site Domaindrivendesign.fr.
Titre de la présentation : Faire marcher les modèles.
Qu'est ce qui paie dans la modélisation ? Pourquoi s'ennuyer avec les modèles ?
Il faut s'accorder sur la définition d'un domaine : une sphère de connaissance, d'influence ou d'activité.
La difficulté critique de la plupart des projets est d'en comprendre la difficulté fonctionnelle.
Pour expliquer sa vision du DDD il prend tout au long de sa présentation le besoin simplifié du transport international.
Il insiste sur le besoin d'un dialogue intelligent avec le client qui connait les besoins fonctionnels.
Le problème est souvent d'utiliser des termes techniques trop rapidement.
Le premier principe est de parler avec un expert du domaine fonctionnel.
Il faut établir une collaboration avec une personne non technique.
(Note personnel : C'est à rapprocher du Behaviour driven development).
Il faut aussi beaucoup explorer (Brainstorming).
Qu'est ce qu'un modèle ?
Un modèle aide à se concentrer sur ce qui est important.
Le modèle choisi doit faire en sorte de faciliter le travail du client (pour expliquer cela, il prend l'exemple de la projection de Mercator qui aide les navigateurs mais n'offre pas une vision correcte de la taille des pays).
Définition d'un modèle : Un système d'abstraction qui décrit une sélection d'aspect d'un domaine et peut être utiliser pour résoudre les problèmes de ce domaine.
Sélectionner le modèle le plus efficace : un modèle doit servir un usage particulier.
Quelle partie du programme vous cause le plus de problèmes ? Peut être y-a-t'il un besoin pour deux modèles ?
Langage d'ubiquité (omniprésent) : un langage structuré autour du modèle du domaine et utilisé par l'ensemble des équipes pour relier toutes les activités avec le programme.
Il y a toujours plusieurs modèles possibles. Chaque département a une vue différente du logiciel.
D'où l'importance du contexte : les paramètres dans lesquels un mot ou une déclaration apparaissent détermine son sens.
Il faut déterminer des frontières à ce contexte.
Eric Evans reprend alors l'exemple du transport en rajoutant un besoin de déterminer un algorithme du plus court chemin. Ce besoin nécessite un modèle complètement différent. Il faut donc apprendre à faire cohabiter deux modèles différents.
Il faut alors mettre ne place une « carte de contexte », une carte qui sert à traduire deux modèles dans deux contextes différents.
Les prerequis pour un modèle sophistiqué sont :
Il faut aussi savoir faire le choix complexe entre revenir en arrière et retravailler le code ou créer un nouveau contexte.
Pour conclure, Eric Evans souligne que tous les gros systèmes ne seront pas bien conçus. Il faut se concentrer sur certaines parties essentielles et les isoler avec des frontières de contexte.
Les ingrédients clés du DDD se trouvent à deux niveaux :
niveau tactique :
Ressources : dddcommunity.org, domainlanguage.com
PS: on me fait remarquer que cette présentation est très proche de celle donnée au Paris JUG. Olivier Croisier en a fait un joli résumé la : http://thecodersbreakfast.net/index.php?post/2009/06/16/Paris-JUG-%22Domain-driven-design%22-%3A-compte-rendu
La soirée a commencé par une présentation du DDD User Group parisien avec Jérémie Grodziski et Grégory Weinbach ainsi que le prochain lancement du site Domaindrivendesign.fr.
Titre de la présentation : Faire marcher les modèles.
Qu'est ce qui paie dans la modélisation ? Pourquoi s'ennuyer avec les modèles ?
Il faut s'accorder sur la définition d'un domaine : une sphère de connaissance, d'influence ou d'activité.
La difficulté critique de la plupart des projets est d'en comprendre la difficulté fonctionnelle.
Pour expliquer sa vision du DDD il prend tout au long de sa présentation le besoin simplifié du transport international.
Il insiste sur le besoin d'un dialogue intelligent avec le client qui connait les besoins fonctionnels.
Le problème est souvent d'utiliser des termes techniques trop rapidement.
Le premier principe est de parler avec un expert du domaine fonctionnel.
Il faut établir une collaboration avec une personne non technique.
(Note personnel : C'est à rapprocher du Behaviour driven development).
Il faut aussi beaucoup explorer (Brainstorming).
Qu'est ce qu'un modèle ?
Un modèle aide à se concentrer sur ce qui est important.
Le modèle choisi doit faire en sorte de faciliter le travail du client (pour expliquer cela, il prend l'exemple de la projection de Mercator qui aide les navigateurs mais n'offre pas une vision correcte de la taille des pays).
Définition d'un modèle : Un système d'abstraction qui décrit une sélection d'aspect d'un domaine et peut être utiliser pour résoudre les problèmes de ce domaine.
Sélectionner le modèle le plus efficace : un modèle doit servir un usage particulier.
Quelle partie du programme vous cause le plus de problèmes ? Peut être y-a-t'il un besoin pour deux modèles ?
Langage d'ubiquité (omniprésent) : un langage structuré autour du modèle du domaine et utilisé par l'ensemble des équipes pour relier toutes les activités avec le programme.
Il y a toujours plusieurs modèles possibles. Chaque département a une vue différente du logiciel.
D'où l'importance du contexte : les paramètres dans lesquels un mot ou une déclaration apparaissent détermine son sens.
Il faut déterminer des frontières à ce contexte.
Eric Evans reprend alors l'exemple du transport en rajoutant un besoin de déterminer un algorithme du plus court chemin. Ce besoin nécessite un modèle complètement différent. Il faut donc apprendre à faire cohabiter deux modèles différents.
Il faut alors mettre ne place une « carte de contexte », une carte qui sert à traduire deux modèles dans deux contextes différents.
Les prerequis pour un modèle sophistiqué sont :
- Avoir acces à des domain experts
- Iteration
- Des frontières claires
Il faut aussi savoir faire le choix complexe entre revenir en arrière et retravailler le code ou créer un nouveau contexte.
Pour conclure, Eric Evans souligne que tous les gros systèmes ne seront pas bien conçus. Il faut se concentrer sur certaines parties essentielles et les isoler avec des frontières de contexte.
Les ingrédients clés du DDD se trouvent à deux niveaux :
niveau tactique :
- Expérimenter des modèles appliqués à des scénarios concrets.
- Collaborer avec les experts du domaine.
- Langage d'ubiquité avec des un contexte limité
- Se concentrer les besoins essentielles (core domain).
Ressources : dddcommunity.org, domainlanguage.com
PS: on me fait remarquer que cette présentation est très proche de celle donnée au Paris JUG. Olivier Croisier en a fait un joli résumé la : http://thecodersbreakfast.net/index.php?post/2009/06/16/Paris-JUG-%22Domain-driven-design%22-%3A-compte-rendu
Commentaires