Je commence à peine à utiliser DDD et je n'arrive pas à trouver comment gérer la nature relationnelle de mes données. J'ai ce que je crois serait considéré comme ma racine agrégée, mais l'agrégat a aussi un agrégat de ses propres. Ne voulant pas violer la loi de Demeter, je me demande si je pense à ce problème et j'espère qu'un expert de DDD pourra nous donner un aperçu.Gérer les agrégats imbriqués dans DDD
Ma racine agrégée est mon objet Account, qui contient un ensemble de nombreuses entités AccountElement, qui sont elles-mêmes des regroupements logiques d'entités individuelles ProductComponent.
Un AccountElement en dehors du contexte d'un Account n'a pas de sens, donc je suis à l'aise avec ma conclusion que l'objet Account est ma racine globale, et je prévois que l'entité ayant une propriété Elements globale. C'est la collection ProductComponent qui m'a confondue. Cet agrégat n'a aucune signification en dehors d'un AccountElement, et vraiment n'a aucune signification en dehors d'un Account.
Je ne pense pas que je devrais accéderont ProductComponent objets individuels par parsèment le chemin à lui, comme:
var reference = account.Elements(0).ProductComponents(0).ReferenceCode;
Mais en même temps, il n'a pas de sens (du point de vue de domaine) à accéder à ProductComponent directement à partir d'une entité Account.
Je suis sûr que tout cela est un peu difficile à comprendre sans la connaissance de mon domaine, mais j'espère que c'est assez pour obtenir de bons commentaires.
Si vous avez besoin de ce niveau d'objets imbriqués pour que votre modèle d'objet fonctionne, alors je ne m'inquiéterais pas trop de la loi de Demeter. Voir http://haacked.com/archive/2009/07/14/law-of-demeter-dot-counting.aspx –
Voir aussi http://www.dcmanges.com/blog/37 –
Merci, l'article de Phil était utile, et la question de savoir comment les enfants des enfants sont inextricablement liés à la racine agrégée est vraiment la clé ici. En regardant cela, il est logique d'imbriquer les entités. Je suis plus à l'aise c'est correct car après avoir pris cette décision la direction du code semble être beaucoup plus intuitive. Ou dans l'esprit de DDD, je ferais peut-être mieux de dire que c'est une abstraction plus vraie du langage omniprésent;) –