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?

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.

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

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.

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.

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. .

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 .