En ce qui concerne DDD, qu'est-ce qu'un contexte borné?
Lorsque j'ai travaillé sur le livre "Implémentation de la conception pilotée par le domaine" de Vaughn Vernon, je n'ai pas réussi à bien comprendre ce qu'est réellement un contexte borné.
Le livre définit un contexte borné comme "une frontière conceptuelle où un modèle de domaine est applicable. Il fournit un langage omniprésent qui est parlé par l'équipe et exprimé dans son modèle de logiciel soigneusement conçu" (le "Guide de ce livre", section de préface). Cette définition donnerait l'impression qu'un contexte borné est le modèle et le langage d'un sous-domaine, où ce sous-domaine peut se trouver être le domaine principal (ce qui semble devoir être appelé "sous-domaine principal", mais c'est une autre discussion ...). Cela laisse encore une certaine ambiguïté quant à ce que fournit un contexte délimité. S'agit-il d'un regroupement d'un ou plusieurs sous-domaines? Si un seul sous-domaine correspond à un contexte borné, que nous dit réellement le contexte borné?
Le chapitre 3 du même livre, cependant, fait référence aux techniques d'intégration entre contextes bornés. Cependant, cela semblerait impliquer que les contextes délimités sont en fait des systèmes logiciels ou des artefacts d'une certaine variété.
Martin Fowler discute brièvement l'idée d'un contexte délimité ( http://martinfowler.com/bliki/BoundedContext.html ), mais ne clarifie pas vraiment le problème.
À la fin de la journée, quel est un contexte borné? Est-ce un regroupement de sous-domaines? Le modèle et le langage d'un sous-domaine? La mise en place d'un sous-domaine? Sans ces réponses, il semble assez difficile de comprendre comment décomposer un espace de problèmes de la vie réelle dans des contextes délimités.
Les contextes et sous-domaines délimités existent à différents niveaux.
Un sous-domaine est une partie de l'espace problématique, c'est un partitionnement naturel du système, reflétant souvent la structure de l'organisation. Ainsi logistique et opérations peuvent être séparés de facturation et facturation. Eric différencie le noyau , supportant et sous-domaines génériques selon leur pertinence commerciale dans le scénario donné.
Les contextes sont des portions de l'espace des solutions. Ce sont des modèles . Ce serait une bonne chose de les avoir, refléter le partitionnement domaines-sous-domaines ... mais la vie n'est pas toujours aussi simple. Et vous pourriez avoir un domaine hérité gonflé englobant tout, ou plus de contexte dans le même sous-domaine (c'est-à-dire l'ancienne application héritée, l'application de remplacement que quelqu'un construit).
Pour avoir un Contexte délimité vous devez avoir un modèle et une limite explicite autour de lui. Exactement ce qui manque dans de nombreuses applications pilotées par les données qui utilisent des bases de données pour partager des données.
Une autre façon - orthogonale - de le voir peut être la suivante. biquitous Language, la condition spéciale où chaque terme a une seule définition non ambiguë, n'est pas mise à l'échelle. Plus vous l'agrandissez, plus l'ambiguïté s'introduit. Si vous voulez obtenir des modèles précis et sans ambiguïté, vous devez rendre leurs limites explicites et parler de nombreuses petites langues omniprésentes, chacune dans un seul contexte borné, avec un objectif bien défini. .
Les techniques de conception pilotée par domaine sont utilisées pour nous aider à créer des modèles du monde dans lequel nous vivons. Ces modèles existent en tant qu'idées dans l'esprit des personnes impliquées dans un projet.
Parce que la télépathie est encore à ses balbutiements, ces idées sont communiquées entre les gens à l'aide de mots et de phrases.
Les mots et les phrases peuvent être ambigus dans le meilleur des cas. Pour nous aider à réduire l'ambiguïté, nous utilisons le "contexte" pour clarifier leur signification.
Lorsque les gens sont profondément immergés dans un projet logiciel qui s'étend sur des années, ils semblent oublier le contexte dont sont issues les idées qui se sont transformées en mots qui se sont transformés en noms de variables qui ont été intégrés dans le code.
Les débutants arrivent au projet et commencent à utiliser et à consommer sa langue. Ce sont peut-être des utilisateurs, peut-être des développeurs. Si aucun contexte ne leur est fourni, ils trouveront leur propre contexte (et, par conséquent, le sens) de leur propre expérience de vie.
Ce contexte nouvellement appliqué guidera la façon dont les nouveaux développeurs refactorisent ou développent le code. S'ils appliquent le mauvais contexte, ils refactoriseront et développeront le code, peut-être un peu toujours, dans la mauvaise direction. Des directions erronées, même minimes, peuvent causer des problèmes beaucoup plus importants sur toute la ligne.
À mon avis, un `` contexte délimité '' n'est qu'un `` contexte clarifié '' qui est remis aux débutants du projet afin qu'ils n'appliquent pas leur propre contexte arbitraire pour entacher notre modèle magnifiquement affiné.
C'est une reconnaissance explicite, par l'équipe, que this phrase, dans this part of the project signifie exactement this thing (et non, comme vous pourriez le penser, that thing).
Tout comme c'est une bonne idée de marquer les limites entre votre jardin et le jardin de votre voisin. Vous spécifiez la limite explicitement afin de ne pas vous mettre en colère quand ils commencent à creuser un parterre de fleurs sur votre pelouse parfaitement entretenue.
C'est ça. C'est une idée très simple qui est si importante que beaucoup a été écrit à ce sujet.
Donc oui. Un contexte borné est littéralement une frontière, une "clôture", qui distingue le contexte d'un sous-domaine du contexte d'un autre sous-domaine dans un projet.
Le modèle et le langage d'un sous-domaine sont isolés des autres modèles et langages pour éviter les ambiguïtés de sens.
Mais oui. Le monde n'est pas si simple.
Vous et l'équipe devez être rigoureux en adhérant au contexte défini. Il est vraiment facile d'être paresseux et de réimaginer le contexte pour couper les coins pendant la construction du logiciel.
En outre, les choses interagissent avec d'autres choses et les contextes délimités doivent également interagir les uns avec les autres. Ainsi, il existe différents modèles pour décrire comment ces interactions se produisent. Voir le livre d'Eric Evan, Domain Driven Design Chapter 14, pour ces différents modèles: noyau partagé, fournisseur client, conformiste, couche anticorruption, voies séparées, service hôte ouvert, langage publié.
Fondamentalement, le contexte délimité définit certaines limites tangibles d'applicabilité de certains sous-domaines. C’est un domaine abstrait où un certain sous-domaine a du sens, tandis que les autres ne le font pas. Cela peut donc être un discours, une présentation, un projet de code avec des limites physiques définies par l'artefact.
Dans différentes situations, j'utilise trois perspectives ou métaphores différentes du concept de contexte borné.
Du point de vue de l'exécution, il représente des limites logiques, définies par le contrat d'un service où le modèle est implémenté. Le contrat peut être représenté comme l'API de ce service ou un ensemble d'événements qu'il publie et consomme. Dans cette perspective, le contexte borné n'a rien à voir avec les limites physiques.
Du point de vue d'un expert en domaine, le contexte délimité est un domaine dans lequel certains processus métier sont mis en œuvre, le certain langage omniprésent est appliqué et certains termes ont un sens clair, tandis que les autres ne le sont pas. Ce n'est donc qu'un rectangle dessiné sur une feuille de papier ou un tableau blanc.
Pour un développeur de logiciels, c'est-à-dire du point de vue du code statique, un contexte borné représente une façon dont j'ai conçu mes modèles autour de sous-domaines correspondants. Avec combien de bases de code un sous-domaine spécifique est implémenté? De quels concepts s'agit-il? Quels concepts sont applicables dans chacun d'eux? C’est pourquoi il est dit que les contextes bornés appartiennent à un espace Solution.
J'aime vraiment this exemple du concept Bounded Context.
Une autre question importante (sinon la plus importante) est comment identifier les contextes bornés . Si vous ne le faites pas correctement, vous vous retrouverez avec services bavards, non maintenables et étroitement couplés , également connu sous le nom de monolithique distribué .