Différences entre DDD et CDEM

Question

Je voudrais savoir s'il y a une différence entre:

Domaine Driven Design (DDD) Model Driven Design (MDD) Je trouve toujours ces deux termes dans de nombreux articles et ouvrages publics , mais personne ne met en évidence les différences.

Answer 1

Les deux approches de conception sont très similaires. Consultez ce lien StackOverflow pour quelques grands, des réponses détaillées sur ce sujet:

Domain Driven Design vs Model Driven Architecture

Pour résumer les réponses dans le lien, les deux approches se concentrent sur la modélisation avec précision un problème avant de concevoir une solution. En général, DDD est considéré comme plus abstrait, sans aucune technologie ou outil de conception spécifiquement suggéré. MDD/MDA est considéré comme plus spécifique, avec des suggestions pour utiliser UML pour le travail de conception.

Answer 2

Je trouve personnellement MDA et DDD assez éloignés les uns des autres. MDA se concentre sur la création de différents types de modèles qui décrivent les systèmes logiciels à différents niveaux. Il encourage l'utilisation de UML pour ces modèles et il pourrait y avoir beaucoup de ces modèles produits pour décrire des systèmes assez complexes à partir de différentes perspectives. Certaines solutions ont été créées, comme Rational Rose, pour générer des logiciels à partir de modèles et les synchroniser avec le code.

Dans le même temps, MDA ne dit rien sur la façon dont vous communiquez à l'entreprise pour comprendre leur domaine de problème. Tout MDA se concentre sur le domaine de la solution.

DDD, d'autre part, est beaucoup plus sur les connaissances sur le domaine et sur la langue. En résumé, beaucoup décrivent DDD comme "développant un langage omniprésent à l'intérieur des contextes bornés". Vous êtes encouragé à parler aux experts du domaine et à comprendre ce qu'ils disent. Vous devez définir des contextes dans lesquels ces termes ont un sens, car la différence de terminologie dans différents contextes peut être extrêmement différente. Chaque contexte est ensuite isolé en un composant hautement cohésif, et une composition de ces composants forment un système complet.

Il existe de nombreux modèles tactiques dans DDD, tels que la racine agrégée, l'entité, l'objet valeur, le référentiel et la fabrique. Mais leur objectif principal est de donner aux développeurs des outils pour créer des abstractions appropriées, qui peuvent encapsuler la connaissance du domaine sans compromettre la lisibilité du code.

La partie la plus importante de DDD est dans des modèles stratégiques tels que les contextes délimités, la carte contextuelle et le langage omniprésent. Si vous n'utilisez pas cela, vous n'avez pas de DDD. Et peu importe, quelle notation vous utilisez pour dessiner des diagrammes (certains utilisent juste des notes autocollantes), c'est complètement secondaire.