DDD, DSL, Modèle et Persistance

[mathias kluba]

Bonjour,

Ca fait beaucoup de choses dans le titre, vous me direz si ça vaut le coup de faire d'autres sujets plus précis.

Premièrement, après le Meetup DDD récemment, j'ai changé ma façon de voir les choses.

Au départ, je croyais que faire du DDD, c'était faire "bien de l'objet", car les notions d'entité/identité/value objects/etc. me rappellent les cours d'objet/UML à l'école. De même, dans la démarche de "modéliser un système", UML est un outil, mais on apprenait aussi à faire un glossaire pour bien comprendre le métier (rendre explicite l'implicite).

Mais j'essaye de faire un rapprochement entre le DDD et le code, alors que le Mapping n'est pas 1:1 : je comprend maintenant que le DDD est une méthode de conception, peut importe le langage ou les Designs patterns.

Ca porte à confusion car les Entities/Value Objects/Aggregate Roots/etc. ça resemble à un design pattern.

Maintenant, je veux modéliser mon métier en DDD. Je peux le faire en Java ou en .Net, mais ces langages ne sont pas porteurs des notions de DDD.

Comment différencier un Value Object d'une Entity, alors que les 2 seront des "class" ?

Certes, on peut différencier les 2 par la manière d'implémenter... mais dans tous les cas, le langage de programmation perd l'information du DDD.

Du coup, j'imagine la modélisation DDD comme un espèce de diagramme UML. C'est d'ailleurs avec des schémas que je représente mon métier (qui ne sont pas strictement UML).

Mais on peut aussi imaginer une DSL pour décrire le modèle: avoir une DSL DDD pourrait porter les informations spécifiques au DDD, et peut ensuite générer une implémentation suivant le langage qu'on désire (ou pas, car on souhaite maitriser l'implémentation).

Une DSL serait pour moi un moyen de communiquer avec le métier.

Je n'ai pas trouvé cette DSL (j'en ai trouvé, mais elles portent sur CQRS qui n'a rien à voir).

Est-ce que l'idée est bonne? Non? Pourquoi? Comment faites-vous pour modéliser un système? Directement par code? Ou d'abords par schéma?

Une fois que j'ai bien modélisé mon métier avec des classes "pures" (sans annotations techniques etc.) je me retrouve à vouloir les persister.

En effet, je pourrais faire de l'EventSourcing, mais je ne le souhaite pas dans mon cas.

De plus, je dépend d'une base de données existante... ce qui arrive fréquemment sur "les projets de la vrai vie".

Ou alors, je commence avec une base vierge, mais les bases relationnels ne sont pas très adapté à mon modèle objet (les ORMs c'est bien, mais ça peut avoir ses limites).

Dans tous les cas, je vais me retrouver avec des contraintes techniques, mais je ne souhaite pas impacter mon modèle métier pour autant.

(Je me souviens que vous disiez que même des annotations JPA ça ne devrait pas être dans le modèle, ce que je comprend tout à fait).

Je retrouve ce type de problème aussi quand je souhaite avoir un modèle spécifique pour des DTO pour un service REST, ou SOAP, ou pour le modèle MVC, etc.

J'ai donc l'impression que je dois faire encore un autre modèle, celui de la persistance, et faire mon mapping avec le modèle métier.

Comment faites-vous cela? Est-ce que vous dupliquer plusieurs modèles, avec du Mapping Object:Object ? Est-ce que vous persistez le modèle "en binaire" ou sous une autre forme (base Document? EventSourcing?) ? Mais alors, pour requêter depuis une interface, dupliquez-vous la persistance dans une autre base ?

Merci par avance pour vos retours d'expérience :)

[Jérémie Grodziski]

Bonjour à tous,

Il y a beaucoup de questions ! :-)

1. Comment différencier un Value Object d'une Entity, alors que les 2 seront des "class" ?

Tu peux leur faire implémenter une interface "Marker" Entity (dans ce cas tu peux avoir une méthode générique pour récupérer l'identifiant) et Value, Repository, etc.

2. DSL 

http://fornax.itemis.de/confluence/display/fornax/Sculptor+(CSC)

Est ce que l'idée est bonne ? oui, en pratique je commence par les scénarios (+ papier/crayon) et je travaille ensuite dans le code (l'IDE facilite cela en Java malgré la verbosité). Je fait un reverse engineering ensuite avec un outil UML pour avoir un beau diagramme une fois que le modèle a un peu "sédimenté".

3. Persistence

Vaste sujet.... je vais faire une réponse assez générale car les questions le sont :-)

A la base, la question que je me poserais est : la structure de données que j'utilise est elle adaptée à mon usage ? les grandes familles de structures permettent de faire un premier choix :

• List/tableau
  
• Map
  
• Graphe/Arbre
  

Les solutions de persistance sont chacune adaptée à un usage qui peut ou pas être relié à l'applicatif ou au domaine suivant les cas. Exemple : le cargo shipping comporte un problème de recherche opérationnel dans un graphe. Je vais ainsi changer de context pour utiliser un logiciel de recherche dans un graphe (concept de noeud, arc, etc.) et faire une context map avec mon problème de port (noeud) et de route maritime (arc).

Chaque solution de persistance répond à une problématique précise qui rejoint le choix de la structure de données la plus adaptée, à charge de faire du polyglot persistence pour répondre à différent usage.

A mon avis les problèmes de mapping sont souvent un symptôme d'une incohérence UI<->domain, domain<->persistence (si on laisse de côté l'intégration d'une base de données Legacy) et/ou problèmes de contexts mélangés.

Jérémie.

2013/3/7 mathias kluba <mathia...@gmail.com>

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes DDD User Group Paris.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse dddugparis+...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 

[Tomasz JASKULA]

Hello Mathias,

Mes réponses sont inline :

2013/3/7 mathias kluba <mathia...@gmail.com>

Bonjour,

Ca fait beaucoup de choses dans le titre, vous me direz si ça vaut le coup de faire d'autres sujets plus précis.

Premièrement, après le Meetup DDD récemment, j'ai changé ma façon de voir les choses.

Au départ, je croyais que faire du DDD, c'était faire "bien de l'objet", car les notions d'entité/identité/value objects/etc. me rappellent les cours d'objet/UML à l'école. De même, dans la démarche de "modéliser un système", UML est un outil, mais on apprenait aussi à faire un glossaire pour bien comprendre le métier (rendre explicite l'implicite).

Le problème de UML lors d'une démarche DDD est qu'il implique trop de "cérémonie" et de friction lorsqu'on peut communiquer plus facilement avec les experts métier par le biais des diagrammes gribouillés sur un paper board très rapidement. Un diagramme UML peut être compris par les experts du métier mais il est trop stricte et ne permet pas de visualiser certaines relations un peu moins explicite entre les différent concepts. Egalement la notion du temps n'est pas très représentable sur du UML. Son utilisation n'est pas cependant proscrite et cela dépend également sur la culture de l'entreprise et la maturité des équipes.

 

Mais j'essaye de faire un rapprochement entre le DDD et le code, alors que le Mapping n'est pas 1:1 : je comprend maintenant que le DDD est une méthode de conception, peut importe le langage ou les Designs patterns.

Ca porte à confusion car les Entities/Value Objects/Aggregate Roots/etc. ça resemble à un design pattern.

C'est bien un pattern tactique de DDD mais cela n'est malheureusement pas suffisant pour tirer pleinement profit du DDD. L'utilisation de ces patterns tactiques sans le pattern stratégique est souvent appelée faire du DDD-light.

 

Maintenant, je veux modéliser mon métier en DDD. Je peux le faire en Java ou en .Net, mais ces langages ne sont pas porteurs des notions de DDD.

Comment différencier un Value Object d'une Entity, alors que les 2 seront des "class" ?

Certes, on peut différencier les 2 par la manière d'implémenter... mais dans tous les cas, le langage de programmation perd l'information du DDD.

Entité => une identité bien défini

VO => différentié uniquement par ces attributs. Donc tu implémentes un Equals et GetHashCode sur toutes les propriétés. Cela permet de distinguer un VO par rapport à un autre.

 

Du coup, j'imagine la modélisation DDD comme un espèce de diagramme UML. C'est d'ailleurs avec des schémas que je représente mon métier (qui ne sont pas strictement UML).

Mais on peut aussi imaginer une DSL pour décrire le modèle: avoir une DSL DDD pourrait porter les informations spécifiques au DDD, et peut ensuite générer une implémentation suivant le langage qu'on désire (ou pas, car on souhaite maitriser l'implémentation).

Une DSL serait pour moi un moyen de communiquer avec le métier.

Oui, DSL c'est tout à fait approprié et très utilisé en DDD. Je parle de DSL interne et non externe.

 

Je n'ai pas trouvé cette DSL (j'en ai trouvé, mais elles portent sur CQRS qui n'a rien à voir).

Est-ce que l'idée est bonne? Non? Pourquoi? Comment faites-vous pour modéliser un système? Directement par code? Ou d'abords par schéma?

En DDD tu n'essais pas de modéliser un système mais juste une partie du modèle stratégique pour l'entreprise. Donc le DSL va s'appliquer uniquement à cette partie là.

 

Une fois que j'ai bien modélisé mon métier avec des classes "pures" (sans annotations techniques etc.) je me retrouve à vouloir les persister.

En effet, je pourrais faire de l'EventSourcing, mais je ne le souhaite pas dans mon cas.

De plus, je dépend d'une base de données existante... ce qui arrive fréquemment sur "les projets de la vrai vie".

Ou alors, je commence avec une base vierge, mais les bases relationnels ne sont pas très adapté à mon modèle objet (les ORMs c'est bien, mais ça peut avoir ses limites).

Dans tous les cas, je vais me retrouver avec des contraintes techniques, mais je ne souhaite pas impacter mon modèle métier pour autant.

(Je me souviens que vous disiez que même des annotations JPA ça ne devrait pas être dans le modèle, ce que je comprend tout à fait).

Je retrouve ce type de problème aussi quand je souhaite avoir un modèle spécifique pour des DTO pour un service REST, ou SOAP, ou pour le modèle MVC, etc.

J'ai donc l'impression que je dois faire encore un autre modèle, celui de la persistance, et faire mon mapping avec le modèle métier.

Oui, mais cela garanti l'indépendance du modèle de domaine.

Si tu n'as pas de contraintes quant à la persistance le problème ne se pose pas. Tu choisi le storage adapté (RDBMS, NoSQL). Dans le cas où les bases existent et t'es obligé de les utiliser alors il faut construire une Anti Corrpution Layer au niveau de l'infrastructure. Cette couche se chargera de persister et de récupérer les données d'une source de données (avec ORM ou pas, selon les besoin et les contraintes) et d'alimenter/mapper sur les entités de ton domaine. Mais en tout cas le domaine ne doit pas avoir de notion de persistance.

 

Comment faites-vous cela? Est-ce que vous dupliquer plusieurs modèles, avec du Mapping Object:Object ? Est-ce que vous persistez le modèle "en binaire" ou sous une autre forme (base Document? EventSourcing?) ? Mais alors, pour requêter depuis une interface, dupliquez-vous la persistance dans une autre base ?

Vraiment cela dépend des cas. Le plus souvent un mapping est le plus efficace et compris par tout le monde. Le requêtage n'est pas une responsabilité du modèle de domaine. Donc cela ne s'applique pas

 

Merci par avance pour vos retours d'expérience :)

--