Qu'est-ce qu'un domaine?
Je vois beaucoup ce terme dans le contexte de l'architecture logicielle ("modèle de domaine", "conception pilotée par domaine", etc.). Je l'ai googlé, mais j'ai des tonnes de définitions différentes. Alors c'est quoi vraiment?
Le mot "domaine" dans le livre Domain Driven Design par Eric Evans a une signification spécifique. C’est la raison d’être du logiciel.
Evans va cependant plus loin. Selon lui, il existe des sous-domaines, même avec le même logiciel. Et c'est la partie du livre qui traite de la "conception stratégique".
Il existe trois "domaines": le domaine principal, le domaine de prise en charge et le domaine générique. Parfois, il les appellera des sous-domaines.
Evans se soucie également profondément de l'activité réelle derrière le logiciel et le livre ne s'adresse pas seulement aux développeurs, mais également aux architectes et aux gestionnaires qui doivent voir comment le logiciel et l'entreprise peuvent travailler ensemble, et c'est ce qui le préoccupe lorsqu'il discute de la conception stratégique et ces sous-domaines.
Le domaine central 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 à d’autres logiciels. Habituellement, Evans le considère comme le domaine contenant le plus petit pourcentage de code. Vous pouvez le considérer comme le 20% le plus important. C'est la partie que vous ne pouvez pas vraiment acheter sur étagère et ce peut être juste un module ou un composant unique du logiciel global.
Le domaine de prise en charge est toujours important et peut être unique pour l'organisation, mais il n'est pas aussi important que le domaine principal. Sans lui, le logiciel n'aura pas autant de valeur et le cœur 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 de soutien pour le cœur.
Le domaine générique est le moins personnalisé et dans un certain sens la partie la moins importante du logiciel. Vous l'avez peut-être écrit en interne, mais il pourrait être plus efficace de l'acheter sur étagère ou d'utiliser un logiciel open source bien connu. Cette partie du système n'est probablement pas spécifique à votre domaine global, donc par exemple si vous avez un système d'expédition qui achemine les colis ou un système de 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 doivent simplement être là pour fonctionner. Cela représente probablement l'essentiel du système dans son ensemble, mais pas nécessairement.
D'un point de vue commercial, il est important de décider quel est votre domaine principal et d'y concentrer vos ressources de développement. Evans a de nombreuses vidéos, notamment sur le site InfoQ, où il explique ces concepts plus en détail.
Ainsi, alors que nous parlons souvent de "domaine" dans les logiciels, dans le cas de DDD, ce n'est pas aussi simple qu'il y paraît.
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 spécialistes du 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 peuvent ignorer ces concepts dans le livre d'Evans, mais je pense que les concepts sont toujours utiles lors de l'écriture et de la planification d'un projet logiciel.
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 l'expertise, le vocabulaire et les outils qui font partie de ce domaine.
Un exemple spécifique d'un 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 y parvient est appelé CNC mill .
Un autre exemple de domaine est le service comptable d'une entreprise.
Lectures complémentaires
Contexte délimité par Martin Fowler
Cela signifie simplement l'espace problématique dans lequel vous travaillez. Par exemple, si vous construisiez un site Web de commerce électronique, votre domaine serait "commerce électronique" et impliquerait les processus associés aux pratiques commerciales de votre client/entreprise. Ainsi, un modèle de domaine serait quelque chose pour représenter un produit ou une facture ou un enregistrement d'expédition.
A Domain is an area of knowledge. It can be though about as an activity in which problems solved by your software exist. ( Wiki , DDD Community )
Eric Evans dans son livre, utilise le 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. Ceux-ci créeront des modèles de domaine, des objets, des services, etc.
Lorsque vous créez une application, vous aurez une sorte d'autorisation, tout comme 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 la façon dont les autorisations sont accordées peut être en dehors du domaine , car les informations peuvent ne pas être pertinentes pour l'expédition de fret.
Autrement dit: un domaine est l'endroit où vous faites affaires . Si votre entreprise expédie du fret, le fret sera votre domaine. Si votre entreprise consiste à authentifier et à autoriser du personnel, ce sera votre domaine.
Extrait de Domain-Driven Design: Tackling Complexity in the Heart of Software , Eric Evans:
Chaque logiciel est lié à une activité ou à un intérêt de son utilisateur. Le domaine auquel l'utilisateur applique le programme est le domaine du logiciel.
Le domaine d'un programme de réservation de ligne aérienne implique de vraies personnes embarquant 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 de logiciels lui-même.
Le modèle de domaine est alors "une abstraction rigoureusement organisée et sélective" des connaissances dans la tête d'un expert de domaine.
Palerme, en décrivant l'architecture de l'oignon, a offert ce résumé
Au centre, 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, propose
Un modèle objet du domaine qui incorpore à la fois le comportement et les données.
Si vous regardez des définitions plus récentes, vous êtes plus susceptible de rencontrer des références 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'accent - la modélisation des comportements (la façon dont les données changent en réponse à des informations extérieures au modèle) a une complexité et une variation plus riches que les différentes façons d'écrire les choses. .
Puisque vous avez probablement déjà une idée de ce qu'est un domaine, je suppose que la prochaine étape que vous prendrez consiste à définir un sous-domaine, un modèle de domaine et, plus important encore, un contexte borné.
Mais je commence par mettre ma perspective du domaine.
Domaine
Le domaine est la réalité que nous habitons: ses entités, leur comportement, les lois auxquelles ils obéissent. Il a existé 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 effectuent des analyses de marché, les gestionnaires de grands comptes communiquent avec les clients, les développeurs de logiciels automatisent les processus métier. C'est pourquoi le domaine est appelé un espace de problème.
Sous-domaines
DDD implique la décomposition du domaine en sous-domaines, pour 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 qui vous gagnez de l'argent. Celui pour lequel nous avons démarré notre entreprise. Donc, même si vous ne connaissez pas un tel mot comme "domaine principal", il est toujours présent. La même chose s'applique aux sous-domaines: vous aurez probablement besoin d'une comptabilité, des ressources humaines, du support technique - mais c'est secondaire.
Modèle de domaine
Il n'est pas nécessaire de modéliser les sous-domaines extraits dans leur intégralité. Il y a 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 atteindre un certain résultat commercial est appelé un modèle.
Contextes limités
La chose la plus importante est que le contexte borné est une frontière logique.
Lorsque les 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 d'applicabilité de certains sous-domaines. C’est un domaine où un certain sous-domaine est logique, tandis que les autres ne le sont pas. Il peut s'agir d'un exposé, 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 borné et le concept de sous-domaine, comment définir les sous-domaines et les contextes bornés, comment représenter leur communication les uns avec les autres et comment organiser les équipes en tenant compte de ces concepts, vous serez probablement intéressé par cette lecture supplémentaire .