3

I have several classes inheriting from an Admin class: Manager, Translator, etc.

Admin is an aggregate, so should have its own Repository. However, some methods to find Managers or Translators might be specific to these classes. Others might be common to all Admins.

What is the best practice here? Should I:

  • put all the methods to find Admins in one Repository?
  • or mimic the hierarchy of domain model classes with a hierarchy of Repositories, then having a ManagerRepository and a TranslatorRepository extending an AdminRepository?
BenMorel
  • 34,448
  • 50
  • 182
  • 322

2 Answers2

3

As I see - it doesn't matter that much.

I would stick with one AdminRepository unless it bloats and begs for decomposition.

Arnis Lapsa
  • 45,880
  • 29
  • 115
  • 195
0

Strictly speaking, only aggregate roots require their own repositories.

In case you need to manage a particular entity without accessing another aggregate root, then that entity can be considered (but not necessarily) an aggregate root itself.

So I'd say: pick your business/domain viewpoint, then draw your technical conclusions.

Roy Dictus
  • 32,551
  • 8
  • 60
  • 76
  • thanks for your answer, but I'm unsure whether you understood the question correctly: Admin is an aggregate root, and its subclasses Manager and Translator are (therefore?) aggregates as well. The question is not whether I should consider them as aggregates, but rather whether they should share one *Repository* or all of them have a Repository. – BenMorel Jun 29 '11 at 14:27
  • 1
    Thanks for the clarification. My thinking on this is: if you want to do the exact same operations on Manager and Translator, so if by and large they are equal citizens, then it would make sense to have a single Repository. If they require different handling or different operations, then I think a separate Repository for each would be best. Just my 2 cents... – Roy Dictus Jun 30 '11 at 13:03