Modélisation de domaine, objets de domaine dans DDD

Question

Je suis vraiment nouveau à DDD et essaye de saisir certains des concepts.

Quelqu'un pourrait-il m'expliquer l'idée derrière Domain Modeling dans DDD.

J'ai déjà parcouru l'explication de wikipedia: http://en.wikipedia.org/wiki/Domain_model mais il semble toujours y avoir quelques zones grises dans ma compréhension.

Sur la base de ce que je compris, la modélisation de domaine consiste à construire un modèle autour des entités commerciales pour exprimer leurs relations, exprimer les entités qui participent au modèle etc ..

est-ce pas quelque chose qui a été dans la pratique toujours? Dans le monde orienté objet, vous modélisez des entités commerciales en classes, objets, etc. et construisez le logiciel autour de cela. Ce que je ne comprends pas est l'accent mis sur la modélisation de domaine dans DDD. Est-ce la même modélisation objet/classe que vous trouvez dans le monde OO, ou est-ce quelque chose de nouveau pour DDD? En quoi diffère-t-il de la conception/modélisation orientée objet?

Vos réponses sont très appréciées.

Answer 1

Une distinction est qu'une implémentation «correcte» du Domain Model Pattern dans DDD est isolée des problèmes transversaux. Par exemple, il ne contient rien à voir avec les bases de données ou toute autre persistance. Lorsqu'il contient une logique de validation, il s'agit d'une validation métier, pas "le nom dépasse-t-il la longueur de la colonne?" validation. L'idée est que le modèle de domaine encapsule «l'entreprise» - en termes commerciaux («langage omniprésent»), dans la mesure du possible - et expose les aspects pertinents de l'entreprise au «programme» sans pour autant accepter le besoins du logiciel. D'un autre côté, "le logiciel" est concerné par les E/S, l'interface utilisateur, etc., mais délègue toute la logique métier au modèle de domaine. En principe, vous pouvez enrober votre modèle de domaine dans un assemblage et l'utiliser dans plusieurs applications. Lorsque les règles métier changent, comme c'est le cas, vous disposez d'un emplacement logique pour modifier les modifications (parce que le modèle est une représentation 1: 1 ou presque des aspects pertinents de l'entreprise et est décrit dans les mêmes termes que les affaires).

Answer 2

Le domaine dans DDD n'a pas besoin d'être implémenté dans OO. D'après mon expérience, un modèle de domaine OO est généralement le meilleur, mais il existe des exemples très valables de situations dans lesquelles ce n'est peut-être pas le cas.

Vous pouvez implémenter un domaine dans des règles, avec un moteur de règles (exemple aux Pays-Bas où cela est fait pour une demande d'hypothèque importante). Ou vous pourriez le faire dans un langage fonctionnel. L'essentiel est que votre domaine, quelle que soit la façon dont il est mis en œuvre, est isolé de ce que j'appelle habituellement les aspects techniques de votre application (ou, comme la réponse précédente l'appelle), des préoccupations transversales, bien que je pense préoccupations transversales dans un domaine). Une couche isolante, qui peut être implémentée à l'aide d'adaptateurs, rend le domaine le plus possible, même complètement indépendant des aspects techniques. Cette couche utilise généralement des motifs tels que Façade et Observateur.