DDD est une méthode de description d'un projet. Un peu comme une méthode Merise ou l'UML. Il semble quand même plus proche des contraintes réelles d'un projet que l'UML. Il introduit des objets de base comme l'entity, le value object, l'event, l'aggregate, le bounding context, le Repository, le service… Le genre d'objet de base qui évite de devoir réinventer la roue à chaque nouvelle modélisation.
On peut trouver nombre d'articles sur le sujet.
Mais connaissez-vous des outils de design ou des bibliothèques "DDD" qui formalisent encore un peu plus son usage ? Ou simplement qui aide à décrire un projet ?
# coquille
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Quelqu'un peut virer le lien du titre, j'ai oublié de nettoyer.
"La première sécurité est la liberté"
[^] # Re: coquille
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 5.
C'est fait (un peu succinct comme titre).
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: coquille
Posté par ZeroHeure (site web personnel) . Évalué à 2.
Mais intrigant ! ;-)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: coquille
Posté par Benoît Sibaud (site web personnel) . Évalué à 9.
Avec juste "DDD" en titre, je m'attendais à un journal sur GNU DDD (Data Display Debugger), la vénérable interface graphique aux débogueurs en ligne de commande comme GNU GDB.
[^] # Re: coquille
Posté par pif17 . Évalué à 2. Dernière modification le 26 avril 2019 à 13:39.
Mais ça prête à confusion, je m'attendait à ce DDD
# UML n'est pas une méthode
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
UML est un langage. Il fournit plein de diagrammes qui peuvent être utilisés dans le cadre de plusieurs méthodes. La méthode "on fait tous les diagrammes possibles de l'UML" n'existe pas. Parce que bien sûr, ça serait irréalisable.
Les créateurs du language UML ont travaillé dans plusieurs équipes avec des méthodes assez différentes, mais ont choisi d'avoir un formalisme commun, leur permettant de partager des outils, des idées, et en général d'échanger plus facilement.
En fonction des projets, et des activités du moment, ça peut valoir le coup de faire un diagramme de classes, un diagramme de déploiement, un diagramme d'états-transitions, un diagramme d'activité, etc, pour y voir plus clair sur un point particulier.
Ensuite, il y a des méthodes qui utilisent le langage UML plutôt que de définir leur propres diagrammes, termes et formalismes. Ce qui permet aussi de mélanger plus facilement certains aspects de différentes méthodes.
[^] # Re: UML n'est pas une méthode
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Oui mais non. Je chercher un outil spécifique DDD.
UML est trés trés gros, et est pensé comme un dessin et non comme un langage, c'est bien le problème. Les machines d'état sont défini de façon ambigüe par exemple. DDD propose des objets de base très intéressant qui pourrait être une lib UML, mais je cherche si un truc dédié existe.
"La première sécurité est la liberté"
[^] # Re: UML n'est pas une méthode
Posté par groumly . Évalué à 4.
DDD est une philosophie de design, pas un framework formel.
Je suis pas sur de comprendre ce que tu cherches comme outil?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: UML n'est pas une méthode
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je sais bien, mais rien n’empêche que quelqu'un ait fait un outil d'aide à la conception DDD. C'est ce que je cherche.
"La première sécurité est la liberté"
[^] # Re: UML n'est pas une méthode
Posté par El Titi . Évalué à 3.
Si tu veux vraiment te lancer dans l'aventure de la modélisation DDD, tu peux peut être jeter un coup d'oeil à Sirius qui est métamodeleur et te permet de créer ton propre DSL graphique.
https://www.eclipse.org/sirius/
Il y'a quelques projets qui peuvent t'inspirer sur le "markeplace"
https://github.com/ObeoNetwork
[^] # Re: UML n'est pas une méthode
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Sirius semble très propre, mais bon de l'Eclipse, du java… cela me motive très peu. Et je trouve UML mal fichu.
"La première sécurité est la liberté"
[^] # Re: UML n'est pas une méthode
Posté par El Titi . Évalué à 2.
Ce n'est pas de l'UML justement.
Ca part d'une implémentation du MOF (https://en.wikipedia.org/wiki/Meta-Object_Facility) dans la spécification de l'OMG pour construire des "Domain Specific Modeling Languages" directement, par opposition aux "General Purpose Modeling Languages" dans lequel s'inscrit UML.
Tu reconstruis ton propre langage directement à partir d'un méta-modèle.
Avec UML; il faut restreindre la sémantique du langage avec des profils et les outils sont souvent moins adaptés pour ce genre de cas d"usages et il faut plus recourir au code
Papyrus (https://www.eclipse.org/papyrus/) s'inscrit dans cette démarche
Sirius adopte la stratégie inverse. Il part de l'Ecore (l'implémentation du MOF pour Eclipse) pour construire ton propre langage et te permet de générer tout le tooling nécessaire (éditeurs, palettes, query, …)
Ces 2 projets s'appuient sur le même cœur, le projet Eclipse Modeling: https://www.eclipse.org/modeling/
Tu peux aussi définir des DSL textuels grâce au même outillage et donc disposer de point de vue différents sur le même modèle:
https://www.eclipse.org/modeling/textual.php
Je ne connais pas d'autres alternatives opensource pour couvrir ce genre de besoins hors du monde Eclipse.
# Domain Driven "Design"
Posté par Narmer . Évalué à 5. Dernière modification le 26 avril 2019 à 22:23.
Hello , comme son nom l'indique le DDD est un type de « conception ». Sa particularité c est qu'elle est pilotée par le domaine, ou encore piloté par le métier. Ce n'est pas une méthode de description à proprement parlé.
Le DDD apporte des blocs de constructions logique qui vont nous aider à appréhender la conception informatique d'un autre point de vue. Il existe deux grandes orientations dans le DDD :
Dans le DDD Tactique, une partie très importante que tu n'as pas mentionné est le découpage en couche ( Interfaces / Applications / Domain / Infrastructure ) .
Une autre approche qui peut se substituer à ce découpage en couche est l'architecture hexagonale qui n'est qu'une variante du découpage en couche dans le DDD Tactique originel. Il introduit les Adapters et les Ports.
Pour répondre à ta dernière question
«connaissez-vous des outils de design ou des bibliothèques "DDD"» . En ce qu concerne les outils de design , les outils classique UML te permettent sans soucis de modéliser ton métier en utilisant les building blocs du DDD.
En ce qui concerne une lib DDD, je comprends ce que tu veux dire. À force de faire du DDD nous nous sommes rendu compte que nous avons pu mettre dans une lib métier qu'on a appeler le « Business Framework » tous les building blocs du DDD Tactique au sein d'une librairie en java que nous avons mis en opensource et disponible ici :
[^] # Re: Domain Driven "Design"
Posté par El Titi . Évalué à 2.
Je ne suis pas certain de ce à quoi l'auteur fait référence mais cela est peut-être lié à l'éternel débat "Anemic" vs "Rich Domain Model" et l'utilisation de frameworks qui ont tendance à s'écarter des fondamentaux de l'approche objet comme Spring Data par opposition au DDD.
https://martinfowler.com/bliki/AnemicDomainModel.html
https://blog.pragmatists.com/domain-driven-design-vs-anemic-model-how-do-they-differ-ffdee9371a86
Dans le monde Java, par exemple un framework comme Axon encourage une approche Domain Driven.
[^] # Re: Domain Driven "Design"
Posté par El Titi . Évalué à 3.
Et pour alimenter la polémique
http://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/
[^] # Re: Domain Driven "Design"
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Bonne introduction pour le DDD. J'ai un bon background en modélisation. Et j'ai pu vraiment me rendre compte que l'important n'est pas d'avoir un seul modèle d'où tout découle, mais dans les transformations entre modèles et leur différente transformation. L'exemple typique est son modèle bien propre, que l'on veut sauver dans une base de donnée. Il y a une infinité de manière de faire. On peut toujours bricoler une sérialisation ad-hoc, mais si on fait une sorte d'ORM automatique, il faut faire un tas de choix qui peuvent avoir de gros impact en performance (primary key, index,…), le pire étant les différences de sémantiques subtiles (gestion des nul ou des string vide, la taille d'entier, cycle de vie, etc…)
Donc, je suis persuadé qu'il faut un modèle "propre" pour faire ses services business, mais un autre modèle dérivé d'un modèle dédié au base de donné. Et le code important devient le code de transformation d'un modèle à l'autre. C'est d'autant plus intéressant si on récupère une base existante.
Donc, je n'aime pas trop le modèle en couche. Soit les couches masquent trop de complexité, et écrire les étages supérieurs devient un calvaire, soit elle rejette la complexité vers les couches hautes, mais sans fournir toutes les informations pour pouvoir réagir correctement. La mode est au micro-service qui sont des découpes verticales. Cela a le bon gout de coller avec le principe de Bounded Context du DDD.
En tout cas, merci pour l'info concernant cet outil.
"La première sécurité est la liberté"
[^] # Re: Domain Driven "Design"
Posté par El Titi . É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
[^] # Re: Domain Driven "Design"
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il faut que je regarde la vidéo. J'ai vu le problème du modèle trop rigide, qui peut casser les anciennes données si il évolue. Mon idée est de plus mettre l'accent sur les transformations plutôt que sur le model lui-même, pour éviter ça. Je pars du principe que le modèle fait parti du code, tout réécrire serait vraiment de la perte de temps.
"La première sécurité est la liberté"
[^] # Re: Domain Driven "Design"
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
J'ai vu la vidéo, mais il passe très vite sur les problèmes du MDA, est-ce que tu as une source sur le sujet ?
"La première sécurité est la liberté"
[^] # Re: Domain Driven "Design"
Posté par El Titi . Évalué à 3.
Je n'ai pas saisi ta remarque précédente ni trop cette question.
Tu parles du MDA, du MDSD ?
Et ca serait un peu long de développer. Sauf si tu me payes une bière :)
Tu connais un peu la spec de l'OMG ?
D'expérience (j'ai bossé sur un projet de déploiement d'une approche MDE pendant plusieurs années) les problèmes sont nombreux et vraiment le Model Driven est aux antipodes des méthodes agiles.
Les seuls usages qui sont encore utiles selon moi sont:
Soit de partir de modèles exprimés dans un DSL textuel et par transformation "Model to Text" générer un artéfact et jeter le modèle à la poubelle.
Lorsque c'est bien fichu on appelle … le scaffolding ou …la compilation
Soit comme déjà évoqué, enrichir suffisamment ton code pour faciliter la rétro-ingénierie à des fins documentaires et éventuellement, refactorer ton code pour aller vers l'architecture cible toujours en bottom up.
L'approche top down est une fausse bonne idée et le roundtrip au delà d'un certaine limite est quasi impossible.
La Hype est bien retombée. Il suffit de voir les tracks modeling à l'EclipseCon pour s'en rendre compte.
[^] # Re: Domain Driven "Design"
Posté par El Titi . Évalué à 3.
Une bonne part de mes critiques rejoignent cet article.
http://www.theenterprisearchitect.eu/blog/2009/06/25/8-reasons-why-model-driven-development-is-dangerous/
et de ce commentaire:
https://softwareengineering.stackexchange.com/a/55698
Surtout concernant la gestion de conf, lorsque tu construis des chaines de transformation de modèles c'est un cauchemar. Ca ne scale pas. Les outils de merge dédiés n'aident pas (Le problème est déjà pa simple pour du code alors imagine pour des fichiers structuré comme le XMI. PAs facile de rendre consistant et atomique un changement réparti (un modèle est un graphe au final)
Ensuite le manque de sémantique d'un modèle (qui est intrinsèquement une abstraction) implique qu'il faut souvent plusieurs points de vue pour effectuer la transformation vers ton modèle/texte cible.
Assurer cette cohérence est complexe et contre productive (Je ne parle même pas de générer des comportements dynamiques)
…
[^] # Re: Domain Driven "Design"
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
un code aussi, non ?
Je ne te suis pas.
"La première sécurité est la liberté"
[^] # Re: Domain Driven "Design"
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
J'ai bossé sur un outil basé sur Papyrus. Et je parle du principe du modèle base design. Pour la bière, si tu es sur sophia anti polis pourquoi pas :)
Tu parles de la congélation du modèle au fur et à mesure qu'il se complexifie ?
"La première sécurité est la liberté"
[^] # Re: Domain Driven "Design"
Posté par El Titi . Évalué à 2.
Ah, les innombrables prémisses et projets dérivés de Papyrus.
Même pour pondre un modeleur qu'on peut mettre entre les mains de non techos sans metter la main à la pâte, on n'y est pas encore.
https://wiki.eclipse.org/Papyrus_for_Information_Modeling
Entre autres.
Aussi du fait que dès que tu enrichis ton modèle dérivé tu dois presque inévitablement retoucher le modèle parent à la main aussi vu que le premier porte plus de sémantique. C'est uen des motivation du MDA. On fait que du top down parce que le reverse est toujours incomplet. Ca devient vite fastidieux.
Tout est expliqué là.
https://www.amazon.com/MDA-Explained-Architecture%C2%BF-Practice-Promise/dp/032119442X
Sur Toulouse, mais ça ma m'arrive d'aller faire un tour du coté de la route des crêtes ;-)
Plus de messagerie privée depuis longtemps sur DLFP
[^] # Re: Domain Driven "Design"
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est souvent parce que la transformation n'est pas controlée, c'est celle de l'outil et rien de plus, non ?
"La première sécurité est la liberté"
# Ressources
Posté par El Titi . Évalué à 3.
Un livre gratuit pour introduire les concepts:
https://www.infoq.com/minibooks/domain-driven-design-quickly
Sinon tootella:
https://github.com/heynickc/awesome-ddd
[^] # Re: Ressources
Posté par El Titi . Évalué à 3.
Complément:
Un livre à prix libre sur la documentation vivante (incluant DDD):
https://leanpub.com/livingdocumentation
et la video d'une conf de l'auteur:
https://www.youtube.com/watch?v=Tw-wcps7WqU
[^] # Re: Ressources
Posté par j_m . Évalué à 2.
Vous ne recommandez pas Domain Driven Design de Eric Evans? C'est un peu le précurseur. Il y a de meilleurs resources?
Je l'ai commencé parce que je le voyais passer dans les bibliographies. Les premiers chapitres ont l'air intéressant.
[^] # Re: Ressources
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
J'ai lu sur internet + son 2ième bouquin beaucoup plus petit et dense.
A priori, le bouquin d'origine est lourd à lire, mais dispose de quelques chapitres qui font référence.
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.