DDD : Obtenir des racines d'agrégats pour d'autres agrégats

Question

J'ai étudié DDD ces deux dernières semaines, et l'une des choses qui m'a le plus frappé est la façon dont les racines agrégées peuvent contenir d'autres racines agrégées. Les racines agrégées sont récupérées à partir du référentiel, mais si une racine contient une autre racine, est-ce que le référentiel a une référence à l'autre référentiel et lui demande de construire la sous-racine ?

Answer 1

@Paco : Vous avez tort. Les référentiels ne servent pas seulement à stocker des objets. Si vous avez lu le livre DDD d'Eric Evan, vous savez que les référentiels sont comme une représentation en mémoire orientée objet des données. Vous pouvez utiliser un objet Repository de la même manière que vous utilisez une Collection. Vous pouvez utiliser l'indexeur pour obtenir ou définir des objets, vous pouvez utiliser la méthode Add() pour ajouter un nouvel objet, vous pouvez utiliser la méthode Remove() pour supprimer un objet, etc.

Le référentiel utilise ensuite l'infrastructure pour lire/écrire des données depuis/vers la base de données. Il peut utiliser un DataMapper pour simplifier l'extraction des données de votre base de données relationnelle et leur mise en correspondance avec vos entités.

Answer 2

Le référentiel ne construit pas mais il stocke. Lorsque vous utilisez ddd, vous pouvez vous familiariser avec les modèles de persistance de base comme l'unité de travail, la carte d'identité, le chargement paresseux, le mappeur de relation d'objet, l'objet de requête, le proxy (dynamique). (ces patterns n'ont rien à voir avec ddd, mais sont très utiles à connaître). Le référentiel n'est qu'une façade pour cacher l'implémentation des patterns mentionnés précédemment et pour abstraire l'accès aux données d'une manière adaptée au domaine. De nos jours, la plupart des gens n'écrivent pas manuellement leur infrastructure de persistance, en particulier lorsqu'ils utilisent ddd, vous pourriez aimer regarder un orm.

La référence réelle avec le code qui convertit les enregistrements de la base de données en un objet sera dans le datamapper. Il y aura des références entre les classes de mapping dans les classes de mapping elles-mêmes, ou créées par quelque chose comme un mapperfactory.

public interface IDataMapper<T>
{
   T Map(IDataReader reader);
}

Vous n'avez pas à implémenter ce code vous-même, utilisez simplement un outil qui le fait pour vous et essayez de comprendre comment certaines parties du code de l'outil (orm) fonctionnent. Le ddd pur sans aucun orm est presque impossible sans un bon ensemble d'outils qui vous évite d'écrire beaucoup de code.

Answer 3

A mon avis, cela dépend. J'ai le même scénario et la façon dont je gère cela est via l'ORM que j'utilise - nHibernate.

J'ai des mappings pour toutes mes entités dont plusieurs sont des racines agrégées et l'une d'entre elles a plusieurs autres racines agrégées comme variables membres. Le référentiel de cette racine agrégée composite ne nécessite pas de références à d'autres référentiels de racine agrégée car nHibernate sait comment obtenir toutes les données requises (via les mappings).

HTH

AWC