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 ?
EDIT :
Étant donné que cette question semble figurer en tête de liste sur Google et que 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
ANCIENNE RÉPONSE (pas si complète :))
Afin de créer un bon logiciel, vous devez savoir ce que ce logiciel ce logiciel. Vous ne pouvez pas créer un système logiciel bancaire si vous n'avez pas n'avez pas une bonne compréhension de ce qu'est la banque, vous devez comprendre le domaine de la banque.
De : Domain Driven Design par Eric Evans.
Ce livre décrit assez bien la DDD.
Inscrivez-vous pour télécharger un résumé du livre o télécharger directement le résumé .
La conception pilotée par le domaine est une méthodologie et une prescription de processus pour le développement de systèmes complexes dont l'objectif est de faire correspondre les activités, les tâches, les événements et les données d'un domaine de problèmes aux artefacts technologiques d'un domaine de solutions.
L'accent de la conception pilotée par le domaine est mis sur la compréhension du domaine du problème afin de créer un modèle abstrait du domaine du problème qui peut ensuite être mis en œuvre dans un ensemble particulier de technologies. La conception pilotée par le domaine, en tant que méthodologie, fournit des lignes directrices sur la manière dont ce développement de modèle et de technologie peut aboutir à un système qui répond aux besoins des personnes qui l'utilisent tout en étant robuste face aux changements dans le domaine du problème.
Le processus de conception pilotée par le domaine implique la collaboration entre les experts du domaine, c'est-à-dire les personnes qui connaissent le domaine du problème, et les experts en conception/architecture, c'est-à-dire les personnes qui connaissent le domaine de la solution. L'idée est de disposer d'un modèle commun avec un langage commun, de sorte que lorsque les personnes de ces deux domaines différents, avec leurs deux perspectives différentes, discutent de la solution, elles discutent en fait d'une base de connaissances commune avec des concepts communs.
L'absence d'une compréhension partagée du domaine du problème 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 qui permet de remédier à cet obstacle.
C'est plus que d'avoir un modèle d'objet. L'accent est mis sur la communication partagée et l'amélioration de la collaboration afin de découvrir les besoins réels dans le domaine du problème et de créer une solution appropriée pour répondre à ces besoins.
Conception pilotée par le domaine : Les bons et les mauvais côtés fournit un bref aperçu avec ce commentaire :
DDD permet de découvrir l'architecture de haut niveau et d'informer sur les mécanique et dynamique du domaine que le logiciel doit reproduire. reproduire. Concrètement, cela signifie qu'une analyse DDD bien faite minimise les malentendus entre les experts du domaine et les architectes de logiciels. logiciels et réduit le nombre de demandes de changement coûteuses. de changement. En divisant la complexité du domaine en contextes plus petits, DDD évite de forcer les architectes de projet à concevoir un objet gonflé. modèle objet surdimensionné, qui fait perdre beaucoup de temps à l'élaboration des détails d'implémentation, en partie parce que le nombre d'entités à traiter entités à traiter dépasse souvent la taille des tableaux blancs des salles de conférence.
Voir aussi cet article Conception pilotée par le domaine pour l'architecture des services qui fournit un court exemple. L'article fournit la description succincte suivante de la conception pilotée par le domaine.
La conception pilotée par le domaine préconise une modélisation basée sur la réalité de l'environnement. des affaires, en fonction de nos cas d'utilisation. Comme elle vieillit et que le le niveau d'engouement diminue, beaucoup d'entre nous oublient que l'approche DDD aide vraiment à aide vraiment à comprendre le problème en question et à concevoir des logiciels en fonction la compréhension commune de la solution. Lors de la création d'applications, DDD parle des problèmes comme de domaines et de sous-domaines. Elle décrit les étapes/domaines indépendants des problèmes en tant que contextes délimités. un langage commun pour parler de ces problèmes et ajoute de nombreux concepts techniques, comme les entités, les objets de valeur et les règles de racine agrégées soutenir la mise en œuvre.
Martin Fowler a écrit un certain nombre d'articles dans lesquels la conception pilotée par le domaine est mentionnée en tant que méthodologie. Par exemple, cet article, BoundedContext fournit un aperçu du concept de contexte délimité du développement piloté par le domaine.
A l'époque, on nous conseillait de construire un modèle unifié de toute l'entreprise. de toute l'entreprise, mais DDD reconnaît que nous avons appris que "l'unification totale l'unification totale du modèle de domaine pour un grand système ne sera pas faisable ou rentable" 1 . Ainsi, au lieu de cela, DDD divise un grand système en contextes délimités, chacun d'entre eux pouvant avoir un modèle unifié. essentiellement une façon de structurer les modèles canoniques multiples.
Vous CAN ONLY Pour comprendre la conception pilotée par le domaine, il faut d'abord comprendre ce que sont les éléments suivants :
Qu'est-ce qu'un domaine ?
Le domaine pour lequel un système est construit. Gestion des aéroports, vente d'assurances, cafés, vols orbitaux, etc.
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 travailler dans les domaines de l'expédition (choisir les moyens de livraison appropriés, en fonction des articles et de la destination), de la tarification (y compris les promotions et la tarification spécifique à l'utilisateur en fonction, par exemple, de sa localisation) et des recommandations (calculer les produits connexes en fonction de l'historique des achats).
Qu'est-ce qu'un modèle ?
"Une approximation utile du problème à résoudre". -- Gerry Sussman
Une classe d'employé n'est pas un employé réel. Elle modélise un employé réel. Nous savons que le modèle ne capture pas tout sur les employés réels, et ce n'est pas son but. Il est uniquement destiné à capturer ce qui nous intéresse dans le contexte actuel.
Différents domaines peuvent être intéressés par différentes façons de 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 le domaine (DDD) ?
Il s'agit d'une approche de développement qui valorise profondément le modèle du domaine et le relie à la mise en œuvre. DDD a été inventé et développé initialement par Eric Evans.
Tiré de aquí
Voici un autre bon article que vous pouvez consulter sur Conception pilotée par le domaine . si votre demande est plus sérieuse qu'un devoir universitaire. 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 de courriels, la persistance de données) et les services qui font réellement des choses qui correspondent aux exigences de votre activité principale.
J'espère que cela vous aidera.
Comme dans TDD et BDD, vous ou votre équipe vous concentrez davantage sur les tests et le comportement du système que sur l'implémentation 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, interfaces utilisateur - communiquent en utilisant le même langage, on parle de conception pilotée par le domaine.
Le DDD est un processus de pensée. Lorsque vous modélisez la conception d'un logiciel, vous devez garder le domaine/processus de l'entreprise 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 les systèmes à l'aide de DDD.
En termes très naïfs, un objet qui
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
