Accéder au contenu principal

Domain Driven Design par Eric Evans

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 :
  • 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.
Niveau stratégique :
  • 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

Posts les plus consultés de ce blog

Summary of 'Clean Architecture' by Robert C. Martin

Summary of 'Clean Architecture' by Robert C. Martin
Uncle Bob, the well known author of Clean Code, is coming back to us with a new book called Clean Architecture which wants to take a larger view on how to create software.

Even if Clean Code is one of the major book around OOP and code design (mainly by presenting the SOLID principles), I was not totally impressed by the book.

Clean Architecture leaves me with the same feeling, even if it’s pushing the development world to do better, has some good stories and present robust principles to build software.

The book is build around 34 chapters organised in chapters.
Programming paradigm After some introduction, there is an overview of three paradigm of programming:

structured programming which imposes discipline on direct transfer of controlobject oriented programming which imposes discipline on indirect transfer of controlfunctional programming which imposes discipline upon assignment

Uncle Bob tells us that each of these paradi…

Le développeur incompétent est un mythe

Sous ce titre complètement arbitraire et très clairement provocateur, je vais passer un contre pied aux derniers articles que j'ai lus sur le métier de développeur.
Par exemple :
http://patricelamarche.net/2011/05/24/lincomptence-des-dveloppeurs/ 
http://blogs.codes-sources.com/tja/archive/2011/10/04/etre-un-bon-d-veloppeur-c-est-aussi-une-question-d-attitude-personnelle.aspx 
Ça tombe bien c'est juste avant la soirée du Paris JUG sur le métier de développeur ! Et comme on se plaint que les présentateurs ne sont pas de vrais (?) développeurs, je vais en profiter pour donner mon avis.

Alors voila, d'après ces articles, un bon développeur connait ses fondamentaux.
Ok soit mais quelle est cette liste de fondamentaux ? 
Chez certains, c'est les maths et l'algorithmie pure, d'autres c'est C++ par coeur et savoir retourner une chaine de caractère en moins de 3 instructions et une seule allocation mémoire, d'autres c'est Java JEE, ses 100 jsr et frameworks in…

Summary of 'Words are windows, Introduction to nonviolent communication' by Marshall Rosenberg

Summary of 'Words are windows, Introduction to nonviolent communication' by Marshall Rosenberg
“Words are windows” is an introduction to non violent communication (abbreviated as NVC). Marshall Rosenberg presents in this book the process that allows us to communicate more serenely with others as well as with ourselves. This mode of communication allows us to become more and more caring, authentic, and empathic with others. It can therefore be used in all interactions of everyday life: as a couple, with our children, at work … NVC is proving to be a very effective way to manage conflicts, and also to better identify our own needs.

At the source of Non Violent Communication NVC has 4 four key components:
Observation – specific facts/data, no evaluation/judgmentFeeling – state how we feel (many failure modes here)Need – the need underlying this feelingRequest – must be specific action to address need
First we observe what is really happening in a given situation. These observatio…