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

Quelqu'un peut-il expliquer (en termes succincts) en quoi consiste exactement la conception pilotée par domaine? Je vois beaucoup le terme mais je ne comprends vraiment pas de quoi il s'agit ni à quoi il ressemble. En quoi diffère-t-il de la conception non pilotée par domaine?

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

ÉDITER:

Comme cela semble être un résultat optimal sur Google et ma réponse ci-dessous ne l'est pas, veuillez vous référer à cette bien meilleure réponse:

https://stackoverflow.com/a/1222488/1240557

VIEILLE RÉPONSE (pas si complète :))

Pour créer un bon logiciel, vous devez savoir de quoi il s'agit. Vous ne pouvez pas créer un système logiciel bancaire à moins d'avoir une bonne compréhension de ce qu'est la banque, il faut comprendre le domaine bancaire.

De: Domain Driven Design par Eric Evans.

Ce livre décrit très bien DDD.

Inscrivez-vous pour télécharger un résumé du livre , ou téléchargez le résumé directement .

La conception pilotée par domaine est une méthodologie et une prescription de processus pour le développement de systèmes complexes dont l'objectif est de mapper les activités, les tâches, les événements et les données d'un domaine problématique dans les artefacts technologiques d'un domaine de solution.

La conception pilotée par domaine met l'accent sur la compréhension du domaine problématique afin de créer un modèle abstrait du domaine problématique qui peut ensuite être implémenté dans un ensemble particulier de technologies. La conception pilotée par le domaine en tant que méthodologie fournit des directives sur la façon dont ce développement de modèle et le développement technologique peuvent aboutir à un système qui répond aux besoins des personnes qui l'utilisent tout en étant robuste face aux changements dans le domaine problématique.

Le côté processus de la conception pilotée par le domaine implique la collaboration entre les experts du domaine, les personnes qui connaissent le domaine problématique et les experts en conception / architecture, les personnes qui connaissent le domaine de la solution. L'idée est d'avoir un modèle partagé avec un langage partagé de sorte qu'en tant que personnes de ces deux domaines différents avec leurs deux perspectives différentes discutent de la solution, elles discutent réellement d'une base de connaissances partagée avec des concepts partagés.

L'absence d'une compréhension commune du domaine problématique entre les personnes qui ont besoin d'un système particulier et les personnes qui conçoivent et mettent en œuvre le système semble être un obstacle majeur à la réussite des projets. La conception pilotée par le domaine est une méthodologie pour remédier à cet obstacle.

C'est plus que d'avoir un modèle objet. L'accent est vraiment mis sur la communication partagée et l'amélioration de la collaboration afin que les besoins réels dans le domaine problématique puissent être découverts et une solution appropriée créée pour répondre à ces besoins.

Conception basée sur le domaine: le bien et le défi fournit un bref aperçu de ce commentaire:

DDD permet de découvrir l'architecture de haut niveau et de renseigner sur la mécanique et la dynamique du domaine que le logiciel doit répliquer. Concrètement, cela signifie qu'une analyse DDD bien réalisée minimise les malentendus entre les experts du domaine et les architectes logiciels, et réduit le nombre ultérieur de demandes de changement coûteuses. En divisant la complexité du domaine dans des contextes plus petits, DDD évite de forcer les architectes de projet à concevoir un modèle d'objet gonflé, ce qui représente une perte de temps considérable pour l'élaboration des détails d'implémentation - en partie parce que le nombre d'entités à traiter dépasse souvent le taille des tableaux blancs de la salle de conférence.

Consultez également cet article Conception pilotée par domaine pour l'architecture de services qui fournit un court exemple. L'article fournit la description miniature suivante de la conception pilotée par domaine.

La conception pilotée par le domaine préconise une modélisation basée sur la réalité de l'entreprise et pertinente pour nos cas d'utilisation. À mesure qu'il vieillit et que le niveau de battage médiatique diminue, beaucoup d'entre nous oublient que l'approche DDD aide vraiment à comprendre le problème à résoudre et à concevoir un logiciel pour une compréhension commune de la solution. Lors de la création d'applications, DDD parle des problèmes en tant que domaines et sous-domaines. Il décrit les étapes / domaines de problèmes indépendants comme des contextes limités, met l'accent sur un langage commun pour parler de ces problèmes et ajoute de nombreux concepts techniques, tels que des entités, des objets de valeur et des règles racine agrégées pour prendre en charge la mise en œuvre.

Martin Fowler a écrit un certain nombre d'articles dans lesquels la conception pilotée par domaine en tant que méthodologie est mentionnée. Par exemple, cet article, BoundedContext , fournit une vue d'ensemble du concept de contexte borné de Domain Driven Development.

Dans ces jours plus jeunes, il nous a été conseillé de construire un modèle unifié de l'ensemble de l'entreprise, mais DDD reconnaît que nous avons appris que "l'unification totale du modèle de domaine pour un grand système ne sera pas réalisable ou rentable" 1 . Au lieu de cela, DDD divise un grand système en contextes délimités, chacun pouvant avoir un modèle unifié - essentiellement un moyen de structurer MultipleCanonicalModels.

Vous NE POUVEZ COMPRENDRE QUE la conception pilotée par domaine en comprenant d'abord les éléments suivants:

Qu'est-ce qu'un domaine?

Champ pour lequel un système est construit. Gestion d'aéroport, vente d'assurance, cafés, vol orbital, vous l'appelez.

Il n'est pas rare qu'une application couvre plusieurs domaines différents. Par exemple, un système de vente au détail en ligne peut fonctionner dans les domaines de l'expédition (choisir les moyens de livraison appropriés, selon les articles et la destination), la tarification (y compris les promotions et la tarification spécifique à l'utilisateur par, par exemple, l'emplacement) et les recommandations (calcul produits par historique d'achat).

Qu'est-ce qu'un modèle?

"Une approximation utile du problème actuel." - Gerry Sussman

Une classe Employé n'est pas un vrai employé. Il modèle un vrai employé. Nous savons que le modèle ne capture pas tout sur les vrais employés, et ce n'est pas le but. Il est uniquement destiné à capturer ce qui nous intéresse dans le contexte actuel.

Différents domaines peuvent être intéressés de différentes manières pour modéliser la même chose. Par exemple, le service des salaires et le service des ressources humaines peuvent modéliser les employés de différentes manières.

Qu'est-ce qu'un modèle de domaine?

Un modèle pour un domaine.

Qu'est-ce que la conception pilotée par domaine (DDD)?

Il s'agit d'une approche de développement qui valorise profondément le modèle de domaine et le connecte à la mise en œuvre. DDD a été inventé et initialement développé par Eric Evans.

Abattu d' ici

Voici un autre bon article que vous pouvez consulter sur la conception pilotée par domaine . si votre demande est quelque chose de sérieux qu'une affectation au collège. Le principe de base est de tout structurer autour de vos entités et d'avoir un modèle de domaine solide. Faites la différence entre les services qui fournissent des éléments liés à l'infrastructure (comme l'envoi d'e-mails, la persistance de données) et les services qui font réellement des choses qui sont vos exigences commerciales principales.

J'espère que cela pourra aider.

Comme dans TDD et BDD, vous / l'équipe vous concentrez plus sur le test et le comportement du système que sur la mise en œuvre du code.

De la même manière lorsque l'analyste système, le propriétaire du produit, l'équipe de développement et bien sûr le code - entités / classes, variables, fonctions, processus d'interface utilisateur communiquent en utilisant le même langage, appelé Design piloté par domaine

DDD est un processus de pensée. Lors de la modélisation d'une conception de logiciel, vous devez garder le domaine / processus métier au centre de l'attention plutôt que les structures de données, les flux de données, la technologie, les dépendances internes et externes.

Il existe de nombreuses approches pour modéliser systerm en utilisant DDD

• sourcing d'événements (utilisation des événements comme source unique de vérité)
• bases de données relationnelles
• bases de données graphiques
• en utilisant des langages fonctionnels

Objet de domaine:

En termes très naïfs, un objet qui

• a un nom basé sur le processus / flux métier
• a un contrôle complet sur son état interne, c'est-à-dire expose les méthodes pour manipuler l'état.
• toujours respecter tous les invariants commerciaux / règles commerciales dans le contexte de son utilisation.
• suit le principe de la responsabilité unique

DDD (domain driven design) est un concept utile pour analyser les exigences d'un projet et gérer la complexité de ces exigences. relations il n'est pas vieux mais il a quelques problèmes:

• Dans les grands projets avec des exigences complexes, cela n'est pas utile, bien qu'il s'agisse d'un excellent moyen de conception pour les petits projets.

• lorsque vous n'avez affaire à aucune personne technique qui n'a pas de concept technique, ce conflit peut causer d'énormes problèmes dans notre projet.

DDD gère donc le premier problème en considérant le projet principal comme un domaine et en divisant chaque partie de ce projet en petits morceaux qui nous sont réputés dans Bounded Context et chacun d'eux n'a aucune influence sur les autres morceaux. Et le deuxième problème a été résolu avec 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 ont suffisamment de connaissances sur leurs besoins

Généralement, la définition simple du domaine est le projet principal qui rapporte de l'argent aux propriétaires et aux autres équipes.

Je crois que le pdf suivant vous donnera une vue d'ensemble. Conception pilotée par domaine par Eric Evans

REMARQUE: pensez à un projet sur lequel vous pouvez travailler, appliquez les petites choses que vous avez comprises et voyez les meilleures pratiques. Il vous aidera également à développer votre capacité à l'approche de conception d'architecture de micro-service.

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

• Ressource pratique: MODÈLES, PRINCIPES ET PRATIQUES DE CONCEPTION DOMINÉE PAR Scott Millett
• Il s'agit d'une méthodologie pour les systèmes commerciaux complexes. Il élimine toutes les questions techniques lors de la communication avec des experts commerciaux
• Il fournit une compréhension approfondie du (modèle simplifié et distillé de) affaires à travers toute l'équipe de développement.
• il maintient le modèle commercial en synchronisation avec le modèle de code en utilisant un langage omniprésent (le langage compris par toute l'équipe de développement, les experts commerciaux, les analystes commerciaux, ...), qui est utilisé pour la communication au sein de l'équipe de développement ou de développement avec d'autres équipes
• Cela n'a rien à voir avec la gestion de projet . Bien qu'il puisse être parfaitement utilisé dans des méthodes de gestion de projet comme Agile.

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

  DDD souligne la nécessité de concentrer le plus d'efforts sur le sous-domaine principal. Le sous-domaine principal est le domaine de votre produit qui fera la différence entre qu'il soit un succès et un échec. C'est le point de vente unique du produit, la raison pour laquelle il est construit plutôt qu'acheté.

  Fondamentalement, 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 simplement l'appliquer à ceux à forte valeur commerciale. (ex pas dans un sous-domaine générique comme email, ...)

• Ce n'est pas 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 Gang of Four) dans vos modèles de domaine. Tout simplement parce que cela ne peut pas être compris par les Business Experts (ils ne connaissent pas grand-chose à Factory, Decorator, ...). Il existe même des modèles dans DDD (tels que le script de transaction, le module de table) qui ne sont pas conformes à 100% aux concepts OO.