Qu'est-ce qu'un domaine?

104

Je vois beaucoup ce terme dans le contexte de l'architecture logicielle ("modèle de domaine", "conception pilotée par le domaine" etc.). Je l'ai googlé, mais j'ai des tonnes de définitions différentes. Alors qu'est-ce que c'est vraiment?

Sipo
la source
12
Malheureusement, je pense que c'est l'un de ces mots qui n'a pas de définition claire et qui est souvent utilisé dans des contextes ambigus. Après l'avoir assez vu, vous acquérez une compréhension. Mon point est que vous ne devriez pas vous attendre à comprendre son utilisation même après avoir lu toutes les réponses que vous verrez ici. Cela prendra du temps.
aaaaaa
15
@aaaaaa exactement ... Humpty Dumpty sourit avec mépris. ... "Quand j'utilise un mot", dit Humpty Dumpty, plutôt méprisant, "cela signifie exactement ce que je veux dire, ni plus ni moins."
emory
3
Je ne pense pas que c'est vrai qu'il n'a pas de définition claire. Si vous regardez la définition normale du webster, vous voyez qu'il s'agit "d'une région sur laquelle le pouvoir est exercé", "d'une région distinctement marquée par une caractéristique physique". Définition similaire en mathématiques - le "domaine" d'une fonction. Vous pouvez fractionner un élément important en domaines ou en régions en fonction de la personne responsable de cette région ou en fonction de certains critères. Un peu comme un module. Ainsi, un «modèle de domaine» (à ma connaissance) est un modèle que vous pouvez utiliser dans la logique métier de votre application. DDD concerne également des types de "régions".
Sava B.

Réponses:

9

Le mot «domaine» dans le livre «Domain Driven Design» d'Eric Evans a une signification particulière. C’est l’objet du logiciel.

Evans va plus loin cependant. À son avis, il existe des sous-domaines même avec le même logiciel. Et c'est la partie de l'ouvrage qui traite de la «conception stratégique».

Il existe trois «domaines»: le domaine principal, le domaine de support et le domaine générique. Parfois, il se référera à ceux-ci en tant que sous-domaines.

Evans est également profondément préoccupé par les activités actuelles du logiciel. Le livre s'adresse non seulement aux développeurs, mais également aux architectes et aux gestionnaires qui ont besoin de savoir comment le logiciel et l'entreprise peuvent fonctionner ensemble. C'est ce qui le préoccupe lorsqu'il discute de conception stratégique. et ces sous-domaines.

Le domaine de base est donc la partie du logiciel qui représente à la fois l’avantage concurrentiel et la «raison d’être» du logiciel. C'est la partie du logiciel qui explique pourquoi un client achèterait le logiciel par rapport à un autre logiciel. En général, Evans le voit comme le domaine contenant le plus petit pourcentage de code. Vous pouvez y voir les 20% les plus importants. C'est la partie que vous ne pouvez pas vraiment acheter sur le marché et il pourrait ne s'agir que d'un seul module ou composant du logiciel global.

Le domaine de support est toujours important et peut être unique à l'organisation mais n'est pas aussi important que le domaine principal. Sans ce logiciel, le logiciel n'aurait pas autant de valeur et le noyau en dépend. Il peut s'agir de plusieurs modules du logiciel que vous avez écrits vous-même et qui remplissent des fonctions importantes mais essentielles.

Le domaine générique est la partie la moins personnalisée et, dans un certain sens, la moins importante du logiciel. Vous l'avez peut-être écrit en interne, mais il serait peut-être plus efficace de simplement l'acheter ou d'utiliser un logiciel open source bien connu. Cette partie du système n’est probablement pas spécifique à votre domaine général. Par exemple, que vous ayez un système d’expédition qui achemine des colis ou un système de gestion des dossiers de santé qui gère les patients, le domaine générique est la partie de ces systèmes qui est commune et juste. Tout simplement besoin d'être là pour fonctionner du tout. Cela constitue probablement l'essentiel du système dans son ensemble, mais pas nécessairement.

Du point de vue commercial, il est important de déterminer votre domaine principal et de concentrer vos ressources de développement là-bas. Evans a de nombreuses vidéos, notamment sur le site InfoQ, où il explique ces concepts plus en détail.

Ainsi, bien que nous parlions souvent de «domaine» dans le logiciel, dans le cas de DDD, ce n’est pas aussi simple que cela puisse paraître.

Je dois noter que les concepts de DDD n'existent pas nécessairement dans la communauté des logiciels au sens large. D'autres développeurs, auteurs et responsables de produit peuvent avoir des idées et des définitions différentes, certaines plus subtiles et d'autres moins. Même d'autres auteurs qui ont écrit sur DDD pourraient passer sous silence ces concepts dans le livre d'Evans, mais j'estime que ces concepts sont toujours utiles pour la rédaction et la planification d'un projet logiciel.

RibaldEddie
la source
1
Votre dernier paragraphe: peut-être devrions-nous nous mettre d’accord sur le domaine de base du développement de logiciels? Mais, comme s’entendre sur la POO, fonctionnel ou tout autre terme, je pense que Humpty Dumpty l’a emporté depuis longtemps.
@nocomprende no, ces concepts sont spécifiques à un logiciel particulier dans une organisation donnée à un moment donné. Le domaine principal de MSFT Windows sera donc différent en fonction des conditions du marché, des attentes des clients, etc.
RibaldEddie
1
Je suppose que cela me rappelle le vieil adage: "Il y a 2 types de personnes: ceux qui divisent les gens en deux types et ceux qui ne le sont pas." Mais ... pour le deuxième type de personnes, il n'y aurait qu'un seul type de personnes ... - erreur d'indirection infinie - système arrêté
@nocomprende désolé, je n'ai pas bien compris votre premier commentaire - le fait de «s'entendre» sur le domaine de base du développement logiciel était une blague.
RibaldEddie
109

Le domaine est le contexte réel dans lequel vous essayez de résoudre un problème à l'aide d'un logiciel. Chaque domaine est livré avec une expertise, un vocabulaire et des outils qui font partie de ce domaine.

Un exemple spécifique de domaine pourrait être quelque chose comme «l’usinage automatisé de pièces complexes à l’aide d’une fraise rotative à grande vitesse». Le système logiciel et matériel qui accomplit ceci s'appelle une fraiseuse à commande numérique .

Le service de comptabilité d'une entreprise est un autre exemple de domaine.

Lectures
suggérées Bounded Context de Martin Fowler

Robert Harvey
la source
4
Ouaip. Lorsque vous lisez "domaine", vous pouvez éventuellement substituer "(restreint à un certain) domaine d'expertise ou de préoccupation".
KlaymenDK
1
La chose intéressante à garder à l'esprit est que le domaine du logiciel n'a vraiment rien à voir avec ce que les humains tentent de réaliser ou ce qu'ils comprendraient. Je suis sûr que le simple ordinateur de ma voiture optimise la combustion, ce que je ne connais pas du tout et qui, franchement, ne s'en soucie pas. Donc, supposer que le logiciel concerne la perspective humaine et les désirs est un malentendu très dangereux. Cela pourrait s'avérer utile, car les systèmes logiciels englobent des zones plus vastes, avec une prise de conscience croissante et une capacité accrue de choisir des objectifs. Hé, attends, Asimov n'y a-t-il pas pensé il y a si longtemps?
1
@ user251748 - Eh bien, je pense que cela concerne les humains et les processus dans lesquels ils sont impliqués, mais pas nécessairement ce que les gens comprennent instantanément.
Sipo
38

Cela signifie simplement le problème dans lequel vous travaillez. Par exemple, si vous construisez un site Web de commerce électronique, votre domaine sera "commerce électronique" et impliquera les processus associés aux pratiques de vente de votre client / entreprise. Ainsi, un modèle de domaine représenterait un produit, une facture ou un enregistrement d'expédition.

Becuzz
la source
7
Euh, étant donné que les sites Web sont domain nameségalement connus sous le nom de domaines, je pense que vous devriez préciser comment vous utilisez le mot domaine ici.
YetAnotherRandomUser
@YetAnotherRandomUser - Pour moi, ce qu'il voulait dire est assez clair. ;)
Sipo
19

Un domaine est un domaine de connaissance. Cela peut être considéré comme une activité dans laquelle les problèmes résolus par votre logiciel existent. ( Wiki , Communauté DDD )

Eric Evans, dans son livre, utilise le transport de fret pour expliquer ce qu'est le DDD. Dans son exemple, le domaine est tout ce qui concerne l' expédition . Comment le fret est déplacé, géré, expédié et suivi, etc. Il est livré avec ses propres règles, langage et processus spécifiques. Celles-ci créeront des modèles de domaine, des objets, des services, etc.

Lorsque vous créez une application, vous disposez d'une sorte d'autorisation, tout comme dans le monde réel de l'expédition, tout le monde ne peut pas accéder aux entrepôts. La manière dont les utilisateurs sont autorisés et les autorisations accordées peut être en dehors du domaine , car les informations peuvent ne pas être pertinentes pour l'expédition de fret.

En termes simples: un domaine est votre lieu de travail . Si votre entreprise expédie des marchandises, les marchandises seront votre domaine. Si votre entreprise authentifie et autorise le personnel, ce sera votre domaine.

potfur
la source
7

De la conception par domaine: aborder la complexité au cœur du logiciel , Eric Evans:

Chaque logiciel est lié à une activité ou à un intérêt de son utilisateur. Le domaine dans lequel l'utilisateur applique le programme est le domaine du logiciel.

Le domaine d'un programme de réservation aérienne implique la présence de personnes réelles dans de vrais avions.

Le domaine d'un programme de comptabilité est l'argent et les finances.

Le domaine d'un système de contrôle de code source est le développement logiciel lui-même.

Le modèle de domaine est alors "une abstraction sélective et organisée du sens strict" des connaissances dans la tête de l'expert du domaine.

Palermo, en décrivant l'architecture de l'oignon, a proposé ce résumé

Au centre même, nous voyons le modèle de domaine, qui représente la combinaison d'état et de comportement qui modélise la vérité pour l'organisation.

Fowler, à son tour, offre

Un modèle objet du domaine qui intègre à la fois le comportement et les données.

Si vous examinez des définitions plus récentes, il est plus probable que vous rencontriez des références indiquant que le modèle de domaine et le modèle de données sont différents . Je ne considère pas qu'un changement de sens autant qu'un changement d'emphase - la modélisation des comportements (la façon dont les données changent en réponse à des informations extérieures au modèle) présente une complexité et des variations plus riches que les différentes façons d'écrire les choses. .

VoiceOfUnreason
la source
Je voudrais modérément ajuster votre définition des activités du monde réel à ce que le système informatique est en train de faire. Par exemple, "Le domaine d'un système de contrôle de code source est" - Stockage et récupération de fichiers de code source . Les domaines sont modélisés, non pas pour gérer des choses du monde réel, mais pour faciliter la construction et la maintenance de systèmes de programmation. L'accent est donc mis sur ce qu'un ordinateur peut faire pour faciliter cela, et non sur ce que les humains peuvent faire. Les rayons X numériques améliorent la sensibilité et le traitement des images du processus de rayons X, ils ne font rien pour les humains et seraient tout aussi utiles pour la numérisation des bagages sans surveillance.
2

Puisque vous avez probablement déjà une idée de ce qu'est un domaine, je suppose que l'étape suivante consiste à définir un sous-domaine, un modèle de domaine et, plus important encore, un contexte lié.

Je commence par mettre mon point de vue de domaine cependant.

Domaine

Le domaine est la réalité dans laquelle nous vivons: ses entités, leur comportement, les lois auxquelles elles obéissent. Il existait avant nous et existera après nous, sous une forme ou une autre. Son existence ne dépend pas de notre conscience. Les spécialistes du marketing proposent de nouvelles fonctionnalités et réalisent des analyses de marché, les responsables de comptes clés communiquent avec les clients, les développeurs de logiciels automatisent les processus métier. C'est pourquoi le domaine s'appelle un espace de problème.

Sous-domaines

DDD implique la décomposition de domaines en sous-domaines, afin de faciliter leur modélisation et leur compréhension. Le fait même que vous dirigiez une entreprise implique qu'il existe au moins une valeur commerciale prédominante. Celui avec lequel vous gagnez de l'argent. Celui pour lequel nous avons démarré notre activité. Donc, même si vous ne connaissez pas un mot tel que «Domaine principal», il est toujours présent. La même chose s'applique aux sous-domaines: vous aurez probablement besoin d'une comptabilité, de ressources humaines, d'un support technique - mais c'est secondaire.

Modèle de domaine

Il n'est pas nécessaire de modéliser intégralement les sous-domaines extraits. Il existe un certain ensemble de règles dans chaque sous-domaine qui nous intéresse. Un ensemble de règles dans un sous-domaine qui est nécessaire pour obtenir un résultat métier donné est appelé un modèle.

Contextes bornés

La chose la plus importante est que le contexte délimité est une limite logique.

Lorsque les deux sous-domaines et le domaine principal sont définis, il est temps d'implémenter le code. Le contexte délimité définit les limites tangibles de l'applicabilité de certains sous-domaines. C'est un domaine dans lequel un certain sous-domaine a un sens, contrairement aux autres. Il peut s'agir d'une discussion, d'une présentation, d'un projet de code avec des limites physiques définies par l'artefact.

Et après?

Si vous êtes intéressé par la corrélation entre le concept de contexte délimité et le concept de sous-domaine, comment définir les sous-domaines et les contextes délimités, comment représenter leur communication entre eux et comment organiser des équipes en gardant à l'esprit ces concepts, cela vous intéresserait probablement. lire plus loin .


la source
Je dirais qu'un domaine pour un logiciel est ce que le logiciel fait. Il n’existait certainement pas avant nous, et c’est entièrement fait par nous, de faire des choses que nous voulons déléguer pour qu’elles se produisent sans notre interaction. En d'autres termes, il s'agit d'un rêve que nous avons eu, que nous voulons oublier. Et nous oublions rapidement le fonctionnement du logiciel dès son déploiement. Le logiciel est un jeu mieux adapté aux ordinateurs à résoudre, nous ne l’avions fait jusqu’à présent car nous n’avions pas encore construit les ordinateurs, afin de résoudre le problème qui ne nous dérangeait plus. Mais très bientôt ...
Je ne me suis pas fait comprendre clairement dans cette partie - "devant nous", mon mauvais. Je ne voulais absolument pas dire que ce domaine existait avant la race humaine. Par "nous", je voulais dire plus comme un développeur de logiciels résolvant un problème d'automatisation, par exemple, de processus commerciaux dans le commerce électronique. Le concept de commerce existait apparemment avant eux. La responsabilité du développeur est donc de rendre possible la délégation de tâches à des ordinateurs, comme vous l'avez dit.
Droite. Ce que je veux dire, c'est que les gens pensent que les systèmes informatiques sont un moyen de faire face au monde réel. Mais les ordinateurs apportent beaucoup d'idées, d'exigences et de préoccupations qui ne faisaient tout simplement pas partie du domaine. C'est comme si on disait que la chirurgie est un moyen de gérer les problèmes émotionnels. La lobotomie fonctionne, mais les problèmes émotionnels ont peu à voir avec le cerveau. Et mes sentiments sont fortement influencés par les hormones et les neurotransmetteurs. Les ISRS font-ils donc partie de la biologie, de la psychologie, des relations ou sont-ils une catégorie à part? Les ordinateurs concernent des ordinateurs, pas de vraies choses.
1
Les ordinateurs consistent à modéliser des choses réelles. Juste un autre domaine dans lequel de vraies choses pourraient être faites, de vrais processus métier pouvant être mis en œuvre, de vraies contraintes métier pouvant être appliquées. pourrait être sans interaction avec l'être humain. Néanmoins, mon argent réel a été retiré de mon compte bancaire réel. Ainsi, peu importe ce qui est impliqué dans un processus quelconque, qu’il soit informatique ou humain ou autre. Cela pourrait probablement vous intéresser: medium.com/@wrong.about/…
L'argent n'est pas réel. Les processus métier ne sont pas réels. Tout ce dont nous pouvons parler est un concept, pas réel.