Les transformations M2M (model 2 model) font aussi partie de la galaxie "Eclipse Modeling" ainsi que la génération de texte à partir de ton modèle (M2T) comme par exemple ton fichier de mapping ORM. https://www.eclipse.org/modeling/transformation.php
L'ennui de cette approche et la principale raison pour laquelle le MDSD (Mode Driven Software Development) a échoué est que cette approche est top down. Ton modèle et ton code se retrouvent à un moment désynchronisé et il n'y a intrinsèquement pas de moyen resynchroniser ton modèle.
C'est pour ça que la notion de "Living Documentation" se retrouve dans tous les concepts liés aux approches agiles y compris pour le DDD.
Dans le BDD (Behaviour Driven Development), tes spécifications son exécutables. Ce couplage implique que tout changement de spec, couvert pas des tests, doit être aligné dans le code si nécessaire et à l'inverse un changement de code qui casse les tests indique soit un bug ou implique une maj de tes specs.
La documentation est toujours à jour.
Le DDD soutient ce principe puisque le métier est directement transcrit dans le code.
La vidéo Youtube que je t'ai pointée est très instructive car elle reprend ce principe à tous les niveaux et y apporte des solutions pratiques.
(Doc utilisateur, archi, specs, ...)
En conclusion disposer d'une représentation de ton métier avec un modèle basé sur les concepts DDD pourquoi pas ?
Mais toujours en respectant les principes agiles, il est plus pertinent d'adopter une approche bottom-up par rétro-ingénierie à partir du code (le réel) quitte à enrichir ce code avec des annotations par exemple. Et on repart du code pour faire évoluer le modèle.
Tu peux aussi pratiquer du sketch modeling à l'ancienne comme base comparative mais toujours en évitant la tentation de regénérer le code (top down).
Le livre et la vidéo de l'auteur détaillent vraiment bien toutes ces pratiques
[^] # Re: Domain Driven "Design"
Posté par El Titi . En réponse au journal Conception pilotée par le domaine ou Domain-driven design (DDD). Évalué à 2.
Les transformations M2M (model 2 model) font aussi partie de la galaxie "Eclipse Modeling" ainsi que la génération de texte à partir de ton modèle (M2T) comme par exemple ton fichier de mapping ORM.
https://www.eclipse.org/modeling/transformation.php
L'ennui de cette approche et la principale raison pour laquelle le MDSD (Mode Driven Software Development) a échoué est que cette approche est top down. Ton modèle et ton code se retrouvent à un moment désynchronisé et il n'y a intrinsèquement pas de moyen resynchroniser ton modèle.
C'est pour ça que la notion de "Living Documentation" se retrouve dans tous les concepts liés aux approches agiles y compris pour le DDD.
Dans le BDD (Behaviour Driven Development), tes spécifications son exécutables. Ce couplage implique que tout changement de spec, couvert pas des tests, doit être aligné dans le code si nécessaire et à l'inverse un changement de code qui casse les tests indique soit un bug ou implique une maj de tes specs.
La documentation est toujours à jour.
Le DDD soutient ce principe puisque le métier est directement transcrit dans le code.
La vidéo Youtube que je t'ai pointée est très instructive car elle reprend ce principe à tous les niveaux et y apporte des solutions pratiques.
(Doc utilisateur, archi, specs, ...)
En conclusion disposer d'une représentation de ton métier avec un modèle basé sur les concepts DDD pourquoi pas ?
Mais toujours en respectant les principes agiles, il est plus pertinent d'adopter une approche bottom-up par rétro-ingénierie à partir du code (le réel) quitte à enrichir ce code avec des annotations par exemple. Et on repart du code pour faire évoluer le modèle.
Tu peux aussi pratiquer du sketch modeling à l'ancienne comme base comparative mais toujours en évitant la tentation de regénérer le code (top down).
Le livre et la vidéo de l'auteur détaillent vraiment bien toutes ces pratiques