#devoxxfr – DDD

Comme le speaker du talk « the quest for infrastructure management » n’est pas là, il y a à la place un talk sur le DDD … Donc allons-y pour le DDD.

Pour s’échauffer, Cyrille Martraire nous parle de son dinsoaure fait avec … un peu de dinosaure.

Donc, c’est parti.
En 2001, avec JavaEE, on nous sort les patterns JavaEE. Et en 2003, c’est le début de DDD.

Beaucoup de monde découvre DDD avec des frameworks, comme CQRS … alors qu’en fait ça ne sert à rien.

Et donc, en DDD, un des trucs importants, c’est d’utiliser un langage commun entre métier et dév … Et évidement, il faut utiliser le langage du métier. Donc, choisissez bien vos mots, sachez précisément ce qu’il veut dire. et n’hésitez pas à utiliser un dictionnaire des synonymes. Du coup, un expert métier serait même capable de reconnaître tous les termes dans les classes. Et pour ça, faire un nuage de mots à partir du code est une bonne idée. Si les mots sont des mots de développeurs, c’est loupé.

Quand est-ce que le DDD est utile ? Quand le métier est riche, quand le métier est complexe, quand c’est important. Parce que ça a un coût, évidement.
Pour avancer dans le DDD, il faut avant tout être curieux du domaine métier.
Ensuite, il faut comprendre vraiment ce domaine, typiquement grâce au BDD.

Voir @carlopescio pour des concepts de physique du code : typiquement, la code gravity où les grosses classes attirent le code.

Pour éviter ça, le DDD recommande vraiment de mettre le code là où c’est utile. Ca veut dire qu’on refactore en fonction du métier, et pas en fonction de Sonar.
Et donc, modéliser un modèle métier en UML, c’est souvent une erreur parce que c’est bien facilement bien trop compliqué.

Il n’y a rien à télécharger pour faire du DDD, mais seulement une boîte à outils méthodologiques. C’est surtout important en java, parce qu’en F# ou Clojure, c’est bien plus facile.

Dans cette boîte à outils, il y a des value objects (égaux par champs), les entités (qui ont un cycle de vie), et les services, qui font des trucs.
Entités et value objects sont newables, et les services sont injectables.

L’un des intérêts des services, c’est que comme ils sont injectables, ils peuvent, dans leurs implémentations, fournir des services techniques (persistance, typiquement). Et c’est bien comme ça qu’on va passer du domaine métier aux services techniques : grâce à la « persistence ignorance ».

On passe ensuite aux bounded contexts, qui permettent d’exposer différents aspects de la même donnée. Leur but, c’est de diminuer le couplage, au prix toutefois d’une duplication de code … au début. Parce que dès que le code évolue, cette duplication n’est plus réelle.

L’avantage, c’est évidement de permettre de séparer les services selon les contextes pour prendre ceux qui sont le plus adaptés.

Très intéressant, même si la plupart des idées, excepté le bounded context, vient en fait du vieux monde de la POO traditionelle (façon C++).

Une réflexion sur “#devoxxfr – DDD

  1. Pingback: #devoxxfr – Rideau ! | riduidel's wordpress

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s