Comment définir clairement les limites d'un contexte délimité

Après environ un mois de lecture et de recherche sur DDD, j'ai décidé de démarrer mon propre projet et j'ai créé DDD avec ces contextes délimités>

• Clients
• Des produits
• Ordres
• Facturation

Chaque contexte borné possède une API de repos en tant que couche de présentation, couche de domaine, couche persistante.

Jusqu'ici tout va bien, le code fonctionne bien, mais venant d'un monde monolithique, j'essaie toujours de comprendre ce qui suit:

• quand je veux créer un nouveau client, émettre une nouvelle facture, créer une nouvelle commande je veux par exemple accéder à la liste des pays. Est ce que je:

a) créer une liste de pays dans chaque BC

b) créer un pays BC -> API et l'utiliser pour obtenir une liste des pays disponibles

c) utiliser une API tierce et extraire des données via une couche anticoruption dans chaque BC

• lors de l'intégration avec une API tierce à l'aide d'une couche anti-corruption ou d'une couche d'adaptateur, quelles données doivent être incluses dans mon modèle de domaine? Par exemple, si je souhaite intégrer une API zendesk à un client BC. Ai-je juste besoin d'un ticketID dans mon domaine, ou dois-je extraire toutes les données de Zendesk auxquelles je veux accéder et utiliser dans un client BC?

Si mon application MVC obtient réellement des données à partir d'API (couches de présentation de mes contextes délimités), je trouve qu'il est très difficile de définir clairement les limites de chaque BC. Cela signifie-t-il qu'un BC correctement conçu servirait un seul contrôleur MVC sans avoir besoin de consommer des API supplémentaires?

Si vos différents contextes délimités comprennent différemment la signification / le but d'un pays, vous devez le modéliser de manière appropriée dans chacun d'eux. Cependant, si nous parlons simplement de données de référence de codes et de noms ISO, je pense qu'il est assez juste et standard de les ranger partout où cela est pratique et de les rendre accessibles à toutes les parties intéressées. Par exemple: une base de données, un fichier de configuration, un service web, etc.

Je voulais aussi regarder un peu votre modèle. Les pièces que vous avez énumérées pourraient très bien être des «entités» dans un «contexte délimité», selon la structure de l'entreprise. Les BC finissent souvent par être définis autour de différents domaines / départements / équipes, car c'est souvent la frontière naturelle entre les «langues omniprésentes». Ainsi, par exemple, au lieu de Ventes / Produits / Commandes, je m'attendrais à ce que les BC soient dans le sens des Ventes / Fabrication / Entreposage.

À l'intérieur de ces BC, vous ne vous concentrez pas sur les noms. Vous vous concentrez sur les cas d'utilisation et créez des modèles de noms pouvant répondre aux cas d'utilisation. Les méthodes sur une "racine agrégée" exécutent des cas d'utilisation et apportent les modifications appropriées aux modèles associés.

... tous les modèles sont faux, mais certains sont utiles.

Gardez également à l'esprit que chaque BC peut utiliser un système ou une architecture entièrement différente. Un BC donné peut ne pas mériter du tout d'utiliser des "composants logiciels DDD", et la plupart d'entre eux ne le font probablement pas. DDD concerne moins les composants logiciels normatifs que le processus de conception de logiciels. Il s'agit de se concentrer sur la compréhension des contextes délimités de l'entreprise, la cartographie des langages omniprésents de chaque contexte et la modélisation du code de ce contexte à l'aide de leur langage omniprésent. De cette façon, lorsque vous interagissez avec les parties prenantes et que vous vous référez au code, il leur semble que vous parlez en termes commerciaux qu'ils comprennent. Et en reconnaissant que le même mot a des significations différentes dans différents BC.

Il y a des modèles spécifiques apportés par DDD (par exemple, référentiel, couches spécifiques, etc.) qui sont des moyens pour une fin. Mais ces modèles ne sont pas garantis comme étant les meilleurs pour chaque cas, même au sein de DDD. Tout comme DDD n'est pas "la" réponse pour chaque projet. Vous n'avez qu'à faire ce que votre analyse suggère est la chose la plus pratique à faire.

D'après vos questions, je pense que vous comprenez mal le contexte délimité. Vous voudrez peut-être relire le chapitre 14 du livre bleu .

Essayer de répondre de manière générale - vous devez faire attention au partage de concepts entre deux contextes bornés différents. Après tout, une partie de la raison pour laquelle la frontière existe est que le langage omniprésent change. Supposer que les mêmes données (et la même représentation) d'une entité peuvent être utilisées dans les deux contextes est naïf - cela peut être vrai, cela peut être faux, mais il n'y a pas de bon moyen pour ceux d'entre nous à l'extérieur, sans accès à vos experts de domaine, à en juger.

Par exemple, dans le domaine client, «pays» peut être lié à la résidence ou à la citoyenneté. Dans la facturation, cela peut être lié aux taux de change. Dans certains de ces domaines, vous devrez peut-être vous soucier des tarifs et autres.

Une deuxième question que vous devez soulever est celle de vos modèles qui constitue le registre des données "partagées". Dans le cas de "pays", la bonne réponse est probablement qu'aucun d'entre eux ne l'est! La topologie géopolitique n'est pas contrôlée par votre modèle.

Que se passe-t-il dans vos modèles de domaine lorsqu'un pays est occupé par une puissance étrangère?

Gardez à l'esprit; beaucoup d'entre nous sont habitués à penser à la structure des données; quelle est la relation entre une donnée et une autre. Et c'est formidable lorsque vous envisagez des rapports et que vous essayez de vous assurer que toutes les données dont vous avez besoin ont été collectées par votre solution. Mais les modèles de domaine ne sont pas seulement une question de structure, mais de changement. Vous devez également porter votre attention sur cette partie et vous assurer de bien comprendre comment les données contraignent les modifications (et comment ces contraintes varient d'un contexte borné au suivant).

Les concepts que vous mentionnez (clients, produits, commandes, facturation) sont généralement représentés dans un modèle de domaine unique et donc dans un contexte délimité. Je suggère que vous comprenez mal ces concepts.

Mon point de vue sur ce sujet est de définir un contexte délimité en utilisant une cartographie des capacités commerciales ou d'autres techniques similaires comme l'analyse de la chaîne de valeur. Cela se résume aux étapes suivantes:

1. Définissez les responsabilités de niveau supérieur de votre système ou les capacités de votre entreprise. Je pense que la meilleure façon de le faire est d'évoquer les étapes que votre entreprise doit suivre pour obtenir une valeur commerciale. Les limites logiques que vous proposez sont vos services commerciaux ou, si vous le souhaitez, des contextes limités.
2. Approfondissez chaque service.
3. Identifiez les communications entre vos services aux côtés des deux premiers points.

Ainsi, l'accent initial est mis sur le fonctionnement de votre entreprise.

Quelques conseils pratiques:

1. Si l'un de vos contextes / services / etc. a besoin d'autres données de contexte, vos limites sont probablement fausses.
2. Le moyen hautement souhaitable de communication contextuelle est basé sur les événements. C'est la clé de l'évolutivité et de la fiabilité. Si vous avez besoin d'une communication synchrone, très probablement, les limites sont erronées, encore une fois. En plus de cela, la communication synchrone tuera votre système.
3. Votre domaine est finalement plus cohérent que vous ne le pensez. Comme tout le monde. N'essayez pas de rendre tout 100% cohérent. Cela n'a aucun sens pratique.
4. Les contextes n'ont pas besoin d'être orchestrés. Ils sont autonomes. Comme les humains.

Avec cette approche, vous vous retrouvez avec des services hautement autonomes, maintenables et fiables. Vous voudrez peut-être vérifier un exemple de définition de limites de contexte.