Qu'est-ce que la conception pilotée par le domaine ?

Question

Quelqu'un peut-il expliquer (en termes succincts) ce qu'est exactement la conception axée sur le domaine ? Je vois souvent ce terme mais je ne comprends pas vraiment ce que c'est ou à quoi ça ressemble. En quoi diffère-t-elle de la conception non axée sur le domaine ?

Par ailleurs, quelqu'un peut-il expliquer ce qu'est un objet de domaine ? En quoi le domaine diffère-t-il des objets normaux ?

Answer 1

Avant cela, les gens analysaient ces exigences en tenant compte des relations entre les classes et les tables et, en fait, leur conception était basée sur les relations entre les tables de la base de données :

• Elle n'est pas utile pour les grands projets aux exigences complexes, bien qu'elle constitue une excellente méthode de conception pour les petits projets.

• lorsque vous avez affaire à des personnes non techniques qui n'ont pas de concept technique, ce conflit peut causer d'énormes problèmes dans notre projet.

Ainsi, DDD traite le premier problème en considérant le projet principal comme un domaine et en divisant chaque partie de ce projet en petits morceaux que nous appelons contexte délimité et dont chacun n'a aucune influence sur les autres morceaux. Le deuxième problème a été résolu grâce à un langage omniprésent qui est un langage commun entre les membres de l'équipe technique et les propriétaires de produits qui ne sont pas techniques mais qui ont suffisamment de connaissances sur leurs exigences.

En général, la définition simple de Domaine est le principal projet qui rapporte de l'argent aux propriétaires et aux autres équipes.

Answer 2

Je ne veux pas répéter les réponses des autres, donc, en bref, j'explique certains malentendus courants.

• Ressource pratique : PATTERNS, PRINCIPES ET PRATIQUES DE LA CONCEPTION AXÉE SUR LE DOMAINE par Scott Millett

• Il s'agit d'une méthodologie pour les systèmes commerciaux complexes. Elle permet de s'affranchir de toutes les questions techniques lors de la communication avec des experts commerciaux.

• Il permet à l'ensemble de l'équipe de développement d'avoir une compréhension approfondie de l'activité (modèle simplifié et distillé).

• il maintient le modèle d'affaires en synchronisation avec le modèle de code en utilisant langue omniprésente (le langage compris par l'ensemble de l'équipe de développement, les experts métier, les analystes métier, ...), qui est utilisé pour la communication au sein de l'équipe de développement ou avec d'autres équipes.

• Cela n'a rien à voir avec la gestion de projet . Bien qu'elle puisse être parfaitement utilisée dans les méthodes de gestion de projet comme Agile.

• Vous devez éviter de l'utiliser dans l'ensemble de votre projet

  La DDD insiste sur la nécessité de concentrer le plus d'efforts sur le sous-domaine central. Le sous-domaine de base est la domaine de votre produit qui fera la différence entre son succès et son échec. Il s'agit l'argument de vente unique du produit, la raison pour laquelle il est construit plutôt qu'acheté.

  En fait, c'est parce que cela prend trop de temps et d'efforts. Il est donc suggéré de décomposer l'ensemble du domaine en sous-domaines et de l'appliquer uniquement à ceux qui ont une valeur commerciale élevée. (par exemple, pas dans les sous-domaines génériques comme l'email, ...)

• Il ne s'agit pas d'une programmation orientée objet. Il s'agit principalement d'une approche de résolution de problèmes et ( parfois ) vous n'avez pas besoin d'utiliser des modèles OO (tels que le Gang of Four) dans vos modèles de domaine. Tout simplement parce qu'ils ne peuvent pas être compris par les experts métier (ils ne savent pas grand chose de Factory, Decorator, ...). Il y a même certains patterns dans DDD (comme The Transaction script, Table Module) qui ne sont pas 100% en ligne avec les concepts OO.

Answer 3

Je pense que le pdf suivant vous donnera une vue d'ensemble. Domain Driven Design par Eric Evans

NOTE : Pensez à un projet sur lequel vous pouvez travailler, appliquer les petites choses que vous avez comprises et voir les meilleures pratiques. Cela vous aidera à développer votre capacité à concevoir l'approche de l'architecture de micro-services.

Answer 4

Obtenez une compréhension du domaine du problème à l'échelle de l'organisation en développant un langage omniprésent (un modèle mental commun) par sous-domaine de problème. Utilisez ce langage aussi étroitement que possible dans les domaines de solution (code). Ensuite seulement, choisissez les technologies. Ne vous laissez pas guider par la technologie, mais par le domaine du problème ou l'entreprise.