DDD, Abstract class, Aggregates and Repository, one or many repository?

user_1632752 0
Viewed 887

Thinking on a repository and aggregate. The literature say that there is one repository per aggregate.

However if my aggregates are all sub classes of a base one (is-a relation, inheritance is not used for reuse). Do I have to create on repository for all sub classes or can I use the same repository for all.

PaperBag paperBag = paperBagsRepository.get(paperBagId);
PlasticBag plasticBag = plasticBagsRepository.get(plasticBagId);

Or

PaperBag paperBag = bagsRepository.get(paperBagId);
PlasticBag plasticBag = bagsRepository.get(plasticBagId);
aggregateroot abstract-class ddd-repositories domain-driven-design
2 Answers

At the application level, you will normally want to have one repository per aggregate. The motivation here is that you are trying to minimize the amount of code that is coupled to the details of your implementation.

See Parnas, 1972.

So in the client code, this style is preferred:

PaperBag paperBag = paperBagsRepository.get(paperBagId);
PlasticBag plasticBag = plasticBagsRepository.get(plasticBagId);

Do you have to do it that way? No. Neither Parnas nor the DDD Police are going to come kicking down your door. But separating out the two makes the code easier to change, which is an important property for sustainable success.

user_547340

In such a scenario, I will ask myself these questions -

  1. Do they represent separate transactions?
  2. Will the events raised vary across types?

Answer to the first question itself will often lead to reasonable aggregate design.

In your specific example, as only the types differ I think they can be created in the same transaction. Also the events raised won't differ across types hence having one repository is better.

user_17630110
Related