Le contexte délimité est un concept important de la conception pilotée par le domaine (DDD), bien que sa mise en œuvre puisse être extrêmement complexe. Il peut s'agir d'une solution technique pour une bonne modélisation du domaine.
Le contexte délimité définit la portée de chaque modèle et assure la cohérence du modèle de domaine dans chaque contexte délimité.
Dans son livre, Vaughn Vernon écrit que le contexte délimité est avant tout une démarcation linguistique. En d'autres termes, les termes et les définitions peuvent avoir des significations différentes en fonction du contexte dans lequel ils s'appliquent.
Cette distinction fait référence à un langage commun, qui est également un autre élément principal de DDD.
Caractéristiques limitées des contextes
- Chaque contexte peut avoir sa propre approche architecturale (couches applicatives, persistance, infrastructure, etc.).
- Chaque contexte délimité peut avoir sa propre méthode de sauvegarde. Par exemple, stockage relationnel, en mémoire ou en cache, etc.
- Tout contexte délimité possède son propre langage unique.
- L'architecture du contexte n'a pas besoin d'être dans un modèle de domaine, elle peut utiliser un modèle à trois niveaux et mettre en œuvre la ségrégation de responsabilité des commandes et des requêtes ou CQRS, l'approvisionnement par événement, etc.
- Un contexte délimité peut être développé par différentes équipes de développement. Il n'est pas nécessaire qu'une seule commande connaisse l'implémentation de tous les contextes, au contraire, pour des raisons de sécurité, la source du contexte restreint peut être limitée à une commande spécifique.
- Les contextes restreints peuvent interagir entre eux de plusieurs façons.
Cartes de contexte
Il y aura des relations et des interactions entre les équipes qui se manifesteront inévitablement dans un contexte délimité approprié. Une carte de contexte est un type commun qui représente les relations entre différentes commandes. La carte de contexte contient plusieurs modèles permettant de représenter la relation entre un contexte restreint:
Le noyau commun
Plusieurs contextes restreints dépendent de ce type de contexte. Il ne peut pas être modifié sans consulter toutes les équipes de développeurs qui en dépendent.
Client/Développeur
L'équipe subordonnée agit en tant que client pour l'équipe supérieure (développeur). Les contextes client dépendent du contexte développeur. Les deux parties se mettent d'accord sur les exigences, puis l'équipe supérieure termine la construction et le développement du modèle et le transfère à l'équipe subordonnée pour une utilisation ultérieure. Le débogage et les tests sont effectués conjointement. Ce modèle est basé sur les amitiés et le soutien de l'équipe.
Conformiste
Il s'agit d'un scénario dans lequel le client et les développeurs ne sont pas d'accord entre eux. Ainsi, le client est contraint d'utiliser ce que le développeur a fourni dans son entreprise, même si cela ne répond pas à ses besoins. Le client doit accepter ce fait et s'en accommoder.
Partenaire
Dans ce cas, les deux équipes dépendent du contexte des deux parties. Elles doivent faire des efforts pour modéliser le projet afin de s'entraider.
Protection contre la corruption
Dans ce modèle, les clients développent une couche supplémentaire de protection contre la corruption pour réduire l'influence des développeurs. Il s'agit d'une situation typique où le modèle de l'équipe supérieure n'est pas amical et ne convient pas à l'équipe subordonnée, mais ils doivent s'appuyer sur ce modèle.
Service d'accueil ouvert
Dans ce cas, des services spéciaux sont offerts que tout le monde peut utiliser. C'est-à-dire que l'équipe peut donner accès au groupe de services à d'autres équipes. Ce modèle est particulièrement utile lorsqu'une intégration avec de nombreux autres systèmes est nécessaire et que la mise en œuvre de ces intégrations prend trop de temps.
Voies séparées
Lorsque la relation entre les deux équipes est facultative. Elles peuvent évoluer et être modélisées indépendamment l'une de l'autre.
Le concept de contexte délimité doit être appliqué pour différencier le comportement d'un domaine en fonction de ses intentions, ce qui permet de comprendre clairement ce qui doit être développé indépendamment et ce qui doit être partagé.