4

I have Category and Product entities. The relationship between the two is one to many. Since, Category is aggregate root I think I should only make a single repository ICategoryRepository which should also handle products.

Ideas?

john doe
  • 41
  • 2
  • My copy of DDD is at home so I'll leave the repositories/aggregate roots question for others, but first, are you sure that Category is really an aggregate root? Simply having a one-many relationship doesn't specify the root. Having this as a root would imply that you only ever retrieve all products in a category. Also, often something like Category would be modelled as a value rather then entity object. – David Hall Jan 25 '10 at 21:54

1 Answers1

4

I'm without my copy of Domain Driven Design by Evans at the moment, which is where I'd turn for the definitive answer, but this reference at dddstepbystep states that:

Within an Aggregate there is an Aggregate Root. The Aggregate Root is the parent Entity to all other Entities and Value Objects within the Aggregate.

A Repository operates upon an Aggregate Root

So yes, going by this definition, your Category Repository should be responsibly for persisting all entities within the Category aggregate.

That said though, my question from my comment still stands - are you sure that Category really is a useful aggregate root? The fact that you are asking this question about persisting products indicates that you often consider them seperate from their Category, or at least would like to be able to deal with some product aside from their category.

David Hall
  • 32,624
  • 10
  • 90
  • 127
  • This is interesting because a Product must have a Category or else it will not exist. So, I think because of this relationship Category is the aggregate root. Please correct me if I am wrong! I think Person and Address also have the same relationship where Person is the aggregate root. – john doe Jan 25 '10 at 22:12
  • @john have a look at this post here: http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/05/20/entities-value-objects-aggregates-and-roots.aspx he talks about with aggregates, roots, entities and values. The key statement is that the root entity is the only entity in the aggregate that can be directly referenced from other aggregates. This isn't to say that your modelling is wrong, just that it seems... odd to me - but I could very well be completely wrong! – David Hall Jan 25 '10 at 22:45
  • I think in that case Product should have a separate rep. Because a customer can add a product in his shopping cart. user.Cart.AddProduct(product). And if make Category as aggregate root then I should traverse the relationship from Category object. – john doe Jan 25 '10 at 23:00
  • @john Have a look at this so post http://stackoverflow.com/questions/25042/am-i-allowed-to-have-incomplete-aggregates-in-ddd I'd agree with the consensus there - from a DDD perspective, having repositories working on parts of an aggregate is a smell. Have you considered having two aggregates, one focused on your category, one on products? Also, in the case you mention, why isn't a product an entity that is part of the order aggregate? So you can reference (through category or not, depending on your root) the product entity from the order and when you save the order also save products. – David Hall Jan 25 '10 at 23:17
  • @john To collapse the above comment a bit - aren't you now dealing with an order/cart aggregate, that has a repository that happens to save the products that are in a cart? – David Hall Jan 25 '10 at 23:18