Contextes et domaines DDD délimités?

J'ai travaillé dans une application relativement complexe avec 10 tables de base de données (agrégats, entités / objets de valeur) et en appliquant DDD. À ce stade, il semble être essentiellement DDD-Lite, ce qui signifie qu'il existe des services d'application / de domaine, le modèle de domaine (entités, objets de valeur) et des référentiels.

J'ai pris un livre sur l' implémentation de DDD et la première chose qu'il mentionne est DDD-Lite et les contextes délimités et les événements de domaine manquants comme premières erreurs qui sont habituelles lors du démarrage de DDD.

Actuellement, j'ai essayé d'organiser le modèle de domaine par relations d'agrégation et d'utiliser des espaces de noms pour le démontrer.

Je n'arrive pas à voir les avantages / inconvénients liés à la séparation du projet de modèle de domaine dans des contextes délimités distincts (pour l'instant). Peut-être que cela deviendra apparent plus tard, mais j'aimerais avoir des commentaires de la vie réelle sur les contextes délimités (et éventuellement des sous-domaines, etc. s'ils y sont liés).

Prenons une entreprise qui a plusieurs départements différents:

• Développement de logiciels
• HEURE
• Comptabilité

Pouvez-vous proposer un modèle utilisateur qui peut représenter de manière expressive tous ces domaines d'activité? Pensez à quoi pourrait ressembler l'entité Utilisateur dans chacune. Il est peut-être divisé en trois entités différentes:

• Développeur
• Employé
• Bénéficiaire

L'effort pour instancier un utilisateur dans chaque contexte est considérablement différent. C'est peut-être quelque chose comme ça:

• nouvel employé (ssn, nom, joindate, date de naissance, sexe)
• nouveau développeur (employé, poste de travail, informations d'identification)
• nouveau bénéficiaire (employé, rôle)

excusez l'exemple, il est difficile d'illustrer avec précision sans un modèle de domaine approprié pour référencer

Si vous utilisiez une implémentation naïve et utilisiez une seule entité utilisateur, cela finirait par être un modèle de données anémique plein de getters et de setters, car vous ne pourriez pas représenter complètement l'utilisateur partout.

Il y a des limites claires dans l'entreprise, il est donc utile de les modéliser de cette façon. Un utilisateur se connectant par rapport à un utilisateur dans un système de paie par rapport à un utilisateur jouant à un jeu sont tous très différents, même s'ils font partie du même grand système.

Penser autrement - vous pouvez maintenant créer votre code de gestion de développeur pour être très léger et indépendant du reste de votre système. Il peut utiliser des types plus précis avec moins de bagages. C'est l'étape de la construction de sous-systèmes plus petits qui peuvent éventuellement être extraits dans sa propre application.

Je peux vous donner un autre exemple. Considérez que vous avez un système de commerce électronique. Vous auriez des produits là-bas, mais les produits feront partie d'au moins deux domaines différents:

• Catalogue de produits, où vous conservez la description de votre produit et tous ses attributs
• Inventaire, où vous avez le niveau de stock des produits

Si vous avez un contexte délimité pour les deux domaines, votre solution peut rapidement devenir une grosse boule de boue car vous commencerez à le croiser. À la fin, vous n'aurez plus deux domaines. Votre inventaire de produits sera gâché avec des références de catalogue de produits et vice versa. En conséquence, vous ne pourrez pas changer de domaine sans en toucher un autre, même si vous réalisez que ce n'est pas nécessaire. Vos modèles deviennent dépendants les uns des autres et étroitement couplés, et dépendent dans le mauvais sens - dépendant de la mise en œuvre.

Cependant, si vous avez deux contextes limités, toutes les modifications que vous effectuez dans un domaine n'affecteront pas l'autre dès que vous gardez vos canaux de communication clairs. Cela signifie que vous devez avoir une duplication des données, mais c'est le moindre coût à payer pour une application basée sur des composants à couplage lointain. Vos domaines peuvent communiquer entre eux à l'aide d'événements de domaine. Même si vous ne prévoyez pas d'avoir une application basée sur SOA au début, vous pourrez évoluer jusqu'à ce niveau lorsque vous en aurez besoin avec un effort relativement faible, car vous modifiez simplement le transport pour vos événements de domaine, en laissant l'idée derrière elle intacte.

Mise à jour: Il y a une bonne diffusion de compétences sur SkillsMatter, d'Eric Evans. Il donne une analogie avec la vieille histoire, lorsque plusieurs aveugles décrivent un éléphant de leur point de vue. Étant donné que chaque homme ne peut toucher qu'une partie de l'éléphant, ils le décrivent comme un "arbre", un "mur", un "serpent", une "corde". Et chacun de ces hommes est dans son contexte. Le contexte borné est celui où vit une langue omniprésente. En dehors du contexte, ces termes peuvent avoir une signification complètement différente mais à l'intérieur du contexte, la langue est la même dans plusieurs domaines. Greg Young suggère fortement de commencer à lire le livre bleu du chapitre 11, car les concepts fondamentaux les plus importants y sont expliqués. L'accent mis sur les schémas tactiques au début du livre rend cette approche «DDD-light» très courante,