2009-08-04 9 views
4

J'ai récemment regardé le Repository Pattern comme un moyen de brosser tous les détails de la persistance sous le tapis où le code client est concerné. En lisant cela, il semble qu'un référentiel est/peut être [habituellement?] Responsable des agrégats plutôt que de simples classes directes.Agrégats et référentiel. Comment déterminer les agrégats?

Ce sens pour moi que vous pourriez avoir une classe de définition messages et une autre définition Commentaires. Cela fait un candidat idéal pour un agrégat, car les deux sont très étroitement liés. Toutefois, comment représenter une classe Users et sa relation avec son Posts?

Serait-il logique pour les utilisateurs globaux avec les Messages/Commentaires global, ou garder utilisateurs par lui-même et tout simplement une association par une bonne vieille référence ancienne?

J'ai essayé de chercher la réponse moi-même en utilisant Google, mais beaucoup d'exemples que je trouve sont simplement autonomes. c'est-à-dire, Messages/Commentaire ou peut-être Ordre et OrderLine etc Je ne trouve rien qui montre comment d'autres classes connexes s'emboîtent.

Je n'applique pas cela à quelque chose de spécifique, même si PHP ou Java/C# serait probablement le domaine que je chercherais à utiliser ces idées. En tout cas, je suis en train d'explorer et d'essayer de comprendre certaines de ces idées et concepts avant de me lancer et de créer un monstre. :)

Nous vous remercions de votre temps.

Répondre

3

Le modèle de référentiel est assez librement défini et n'a pas nécessairement de relation avec le modèle agrégé. Cependant, si vous vous abonnez à la façon DDD de faire les choses, alors oui, les dépôts sont uniques aux agrégats. Voyons donc ceci du point de vue DDD. DDD dit que les objets dans un agrégat peuvent avoir une référence à une autre racine agrégée, mais les objets dans un agrégat ne sont accessibles que via la racine. La règle de base pour déterminer les agrégats est ce qui devrait être supprimé lors de la suppression de la racine. Cependant, DDD décourage l'utilisation des relations plus que la plupart des méthodologies disant que juste parce qu'une relation existe dans un domaine, elle n'a pas besoin d'exister dans votre modèle du domaine, alors gardez cela à l'esprit.

Dans votre cas, lorsque vous supprimez un post, je suppose que vous supprimez également les commentaires, mais pas l'utilisateur qui a créé le post ou les utilisateurs qui l'ont commenté. Par conséquent, vous avez raison de définir l'agrégat de publication/commentaire, mais cela n'aurait aucun sens de regrouper des utilisateurs dans cet agrégat.

Les utilisateurs, étant son propre agrégat, peuvent contenir une relation avec tous leurs messages, car la publication est la racine agrégée. Vous pouvez également implémenter cette méthode sur PostRepository pour obtenir tous les messages d'un utilisateur donné. J'espère que cela pourra aider!

+0

Ah je comprends. Si un objet dépend entièrement d'un autre, il est logique de les agréger. Donc, les commentaires ne peuvent pas exister sans messages. Même si je suppose que vous devez tracer la ligne à certains endroits - Supprimer un utilisateur ne signifie pas nécessairement que ses messages/commentaires disparaissent, et même s'ils l'ont fait, il est plus logique d'avoir des utilisateurs en tant qu'entité distincte. En aparté, où est l'endroit logique pour mettre le SQL réel pour interroger la base de données [ou quel que soit le mécanisme que j'utilise pour la persistance]? Serait-ce dans le référentiel ou les agrégats ... ou même plus bas?Merci de votre aide! – Etzeitet

+0

Vous l'avez. Le référentiel * agit * comme s'il s'agissait d'une collection en mémoire, mais est implémenté pour accéder à votre magasin de données. Cela signifie que l'interface du référentiel n'a aucune mention de SQL ou d'accès aux données, mais l'implémentation le fait, c'est votre abstraction. –

Questions connexes