Contextes du mappeur Supercontexts: découplage des contextes délimités spécifiques au domaine et génériques au domaine

(1er août 2019)

Vous créez un nouveau système et deux membres de votre équipe proposent des architectures alternatives pour lenvoi de notifications. Lequel est correct?

Le premier développeur propose un modèle push: les contextes bornés doivent indiquer au contexte des notifications denvoyer une notification. Le contexte Notifications (Notifications) doit simplement obéir aux commandes dautres contextes et envoyer des notifications lorsque vous y êtes invité.

Le deuxième développeur naime pas le modèle push et propose une solution chorégraphiée: lorsque des contextes limités déclenchent des événements, les notifications doivent écouter et déterminer quand envoyer une notification.

Comment définiriez-vous la solution? Plus important encore, comment résoudriez-vous cette décision au sein de léquipe? Comment allez-vous concevoir larchitecture la plus efficace qui prend en charge les objectifs à court terme et lévolution à long terme?

Avoir des compétences DDD dans léquipe est un avantage majeur. Être capable danalyser votre domaine pour comprendre les fonctionnalités de base, de support et génériques vous permet de faire des compromis dingénierie judicieux.

Explorons ce scénario plus en détail avec une perspective DDD.

Domaine Analyse des capacités

Largument de loption 1 (commandes poussées) est que le générique (Notifications) ne doit pas dépendre du spécifique. Si quelque chose est générique dans de nombreux domaines, il est logiquement faux sil est couplé à quelque chose dans un seul domaine.

Au-delà du raisonnement abstrait, de quoi cette heuristique nous met-elle en garde? Quelles sont les conséquences techniques dont nous devons être conscients?

Il y a deux scénarios que nous voulons éviter:

  1. Éviter que la logique propre à un domaine ne sinfiltre dans des contextes génériques entraînant des co -change
  2. Impossibilité de réutiliser ou de remplacer des contextes génériques par une solution prête à lemploi en raison dun couplage trop étroit avec des contextes délimités spécifiques au domaine

Couplage du domaine et des responsabilités génériques

Avec loption 1, il ny a pas de co-changement entre les API spécifiques au domaine et génériques au domaine. Si une nouvelle notification est nécessaire, seuls les contextes spécifiques au domaine changent. Mais ce nest pas le cas avec loption 2.

Avec loption 2 (chorégraphiée), si un nouvel événement est introduit qui nécessite des notifications, une API spécifique au domaine devra publier le nouvel événement et le service de notifications devra sabonner à lévénement et envoyer une notification. Cela ne semble pas correct – la connaissance du domaine se cache dans le contexte générique.

Isoler les capacités génériques

Si le service de notifications est vraiment générique et réutilisé dans de nombreuses équipes ou même un organisation, il aura besoin de connaître des centaines dévénements de domaine. Et avec autant déquipes en fonction du contexte des notifications, cela deviendra sûrement un goulot détranglement réduisant son potentiel de réutilisation dans une organisation.

Un autre commentaire sur la conception est que nous ne pouvons pas remplacer le contexte générique par un solution prête à lemploi. Sil est vraiment générique dans de nombreux domaines et que nous ne pouvons pas le remplacer par une solution prête à lemploi qui a plus de fonctionnalités et coûte moins cher à exécuter, la conception indique que quelque chose ne va pas.

Les commandes spécifiques au générique sont donc une meilleure pratique?

Toutes les preuves suggèrent que loption 1 est correcte: les contextes spécifiques au domaine devraient envoyer des commandes aux contextes génériques du domaine pour les dissocier de la logique du domaine. Cependant, notre analyse a été superficielle. Nous devons analyser le domaine plus en détail pour nous donner la confiance que nous faisons de bons choix dingénierie.

Analyse de domaine plus approfondie

En regardant de plus près loption 1 (instructions spécifiques génériques), chaque domaine – Le contexte spécifique qui doit envoyer des notifications a pris une responsabilité supplémentaire. Il a besoin de savoir quand envoyer des notifications et quel type de notification envoyer.

Est-il judicieux de répartir la logique des notifications dans tous les contextes délimités? En plus du code enchevêtré, cela pourrait signifier une coordination à grande échelle entre de nombreuses équipes si lapproche des notifications change.

Il existe également un risque accru ou des incohérences et des doublons / gaspillages si chaque équipe adopte sa propre approche des notifications. Les bibliothèques partagées sont une possibilité, mais elles ne résolvent pas tous les problèmes et elles apportent également des compromis.

Certains concepts de domaine se partitionnent clairement (triangles rouges, gris, jaunes; cercles bleus) mais certains ont se chevauchent sur différentes dimensions et peuvent être catégorisées de plusieurs manières (triangles bleus)

Chaque fois quil est difficile de décider si une responsabilité doit appartenir à un contexte ou à un autre, zoomez et décomposez davantage la responsabilité. Recherchez les sous-responsabilités qui peuvent être dissociées – il existe peut-être un concept de domaine caché.

Lorsquun concept ne sintègre pas clairement dans un contexte limité, analysez-le plus en détail pour identifier les sous-responsabilités. Peut-être y a-t-il un concept de domaine caché qui peut produire un modèle proprement partitionné.

Zoom sur la responsabilité litigieuse de lenvoi de notifications, pourrait-il y avoir un concept manquant ? Il existe peut-être un troisième concept qui lie le domaine spécifique au domaine générique pour fournir un modèle plus élégant.

Contextes du mappeur de domaine

Un modèle qui peut être utilisé pour découpler le domaine spécifique et domain-generic est le contexte du mappeur de domaine. Lorsquun contexte assume ce rôle, il écoute les événements de domaine spécifiques et les mappe sur des commandes envoyées à un contexte générique.

Remarquez comment les compromis de ce modèle se comparent aux avantages et aux inconvénients des deux options initiales. Il offre les avantages des deux: la liberté de changer la façon dont les notifications sont envoyées sans encombrer chaque contexte spécifique au domaine avec une complexité liée aux notifications.

Considérez le scénario: un système de notifications interne doit être remplacé par une solution prête à lemploi. Le mappeur de domaine acheminerait toutes les commandes vers le nouveau service de notifications, sans quaucun contexte spécifique au domaine ne soit affecté.

Considérez un autre scénario: une nouvelle notification doit être ajoutée. Un enregistrement serait configuré dans le mappeur: lorsque l {événement du domaine} déclenche {notification}.

Les notifications sont une fonctionnalité générique de domaine – de nombreux domaines exploitent les notifications par e-mail et push
Préférences de notifications sur Twitter – mappage de lévénement spécifique au domaine vers les actions génériques du domaine (e-mails)

Pourquoi appeler les contextes du mappeur?

Le la dénomination de ce modèle est significative. Les actions qui se produisent à lintérieur dun domaine sont mappées sur des actions qui se produisent dans un autre domaine (un contexte générique est générique dans de nombreux domaines, donc partiellement dans un autre domaine).

Vous pouvez avoir des similitudes avec dautres modèles comme traducteur de messagerie , cependant la traduction implique une certaine équivalence; la valeur traduite est une représentation différente de la valeur dorigine. Avec un mappeur, ce nest pas le cas.

Un mappeur est plus un auditeur, observant ce qui se passe dans le domaine. Il décide de la manière de répondre aux événements du domaine par une action dans un autre domaine.

Gateway Domain Mapper Contexts

Si vous décidez de remplacer votre création personnalisée contexte générique avec une solution SaaS, votre contexte de mappeur de domaine devient un contexte de mappeur de domaine de passerelle.

A La passerelle se trouve à la périphérie dun système gérant les entrées et les sorties dinformations

Un contexte de mappeur de domaine de passerelle remplit essentiellement la même fonction, mais il se trouve maintenant à la périphérie de votre système et communique au-delà des limites du système. Cest une voie pour les informations entrant et sortant du système.

Limplémentation peut se ressembler, mais avoir une terminologie plus précise est utile pour vous permettre de communiquer votre architecture plus clairement.

Compromis dingénierie du mappeur de domaine

Les modèles associés aux contextes du mappeur de domaine ne sont pas négligeables. La couche de cartographie supplémentaire signifie quil y a maintenant trois collaborateurs impliqués. Plus de choses qui peuvent échouer.

Il y a aussi le co-changement. Lorsque de nouveaux événements sont introduits ou que des événements existants changent, les contextes spécifiques au domaine possédant les événements et le contexte du mappeur devront changer.

Il existe des solutions largement utilisées pour minimiser ces coûts.

Contextes du mappeur de domaine en libre-service

Un modèle fréquemment rencontré dans la nature est le contexte limité en libre-service. Un contexte limité jouant ce rôle permet aux consommateurs dexploiter les capacités du contexte sans être bloqués par léquipe qui possède le contexte.

La première variante est un mécanisme de compilation via le contrôle de code source et la seconde est un mécanisme dexécution via Appels API.

Dans le scénario des notifications, le contexte de libre-service pourrait fournir un DSL. Les équipes qui possèdent des contextes spécifiques au domaine créeraient une demande dextraction contenant des modifications dans un fichier de configuration (encore mieux – un code qui compile et est testé), qui, à laide du DSL, configure un mappage entre un événement de domaine auquel sabonner et une notification à être envoyé.

Avec la version dynamique, la configuration correspondante serait effectuée via un appel API ou une interface utilisateur. Lorsque la configuration dynamique est possible et quil ny a pas de dépendances au moment de la compilation sur le domaine, le contexte change pour devenir entièrement générique. Cest un modèle évolutif courant ().

Langue publiée

Un autre modèle DDD à considérer dans ce type de scénario est la langue publiée. Tout événement qui déclenche une notification doit faire partie dune langue publiée.

Une langue publiée est un contrat ou un accord sur le format des messages produits par un contexte limité. Sassurer que les événements qui nécessitent une notification font partie dune langue publiée signifie que plus de précautions doivent être prises pour assurer la compatibilité ascendante et informer les consommateurs des modifications futures.

Dois-je toujours utiliser des contextes de mappage de domaine?

Certainement pas. Chacun des modèles présentés dans larticle est valide et utilisé avec succès dans une variété de systèmes. Les contextes de mappage de domaine sont un autre modèle avec des compromis clairs que vous pouvez utiliser pour explorer dautres possibilités de modélisation.

La recherche de supercontextes

Il est facile de modéliser des domaines à un niveau naïf ou superficiel . Lorsque vous entendez un mot comme «notifications», il est facile de tomber dans lerreur de nom cohérent, en supposant que, parce quun mot sonne comme un seul concept, il doit être représenté par un seul contexte borné dans notre système.

Lorsque nous utilisons DDD pour analyser à un niveau plus profond et que nous cherchons à séparer les concepts spécifiques au domaine et génériques au domaine, nous constatons souvent quil existe plusieurs façons de modéliser le domaine, y compris en ayant plusieurs contextes bornés – délimitant le domaine spécifique du domaine générique – dans un seul supercontexte.

Découpler le domaine spécifique du domaine générique ne consiste pas à créer de beaux modèles abstraits qui suivent danciennes règles DDD, il sagit de découpler des concepts qui changent ensemble pour différentes raisons afin que nous puissions concevoir le commerce -offs qui permettent aux systèmes dévoluer plus facilement.

Essayez déviter lerreur de classification de domaine unique: en supposant quune capacité de haut niveau, Notifications, doit avoir une seule classification de domaine (par exemple générique).

En orde r pour obtenir des informations plus approfondies sur le domaine, je recommande dintégrer les compétences DDD et les activités DDD dans le mode de travail de votre équipe. Expérimentez avec EventStorming et (The Bounded Context Design Canvas) comme point de départ pour apprendre à modéliser des contextes mieux délimités.

Formation et conseil

Si vous cherchez de laide pour explorer votre domaine, la conception de votre système ou la formation de vos équipes, contactez-moi pour plus dinformations. Je travaille avec un réseau de praticiens DDD hautement expérimentés passionnés par la conception de systèmes sociotechniques efficaces alignés sur les objectifs et le domaine de lentreprise.