In domain driven design, can entities have their own repositories?

Question

Hi all,

I'm working a pretty standard e-commerce web site where there are Products and Categories. Each product has an associated category, which is a simple name-value pair object used to categorise a product (e.g. item 1234 may have a category "ballon").

I modelled the product as a root aggregate, which owns and knows how to modify it's category, which is an entity.

However, I ran into a problem where a user needs to be able to search a category. How am I supposed to implement this in DDD? I'm new to DDD but I believe that only root aggregates should be given it's own repository. So that leaves me with 2 options:

1. Add "SearchCategory" method to the ProductRepository
2. Implement the search logic as service (i.e. CategoryFinderService)

I personally think option 2 is more logical but it feels weird to have a service that touches database. Somehow I feel that only repository should be allowed to interact with database.

Can someone please tell me what's the best way to implement this?

Answer 1

IMHO, in your Domain Model, Category should not be child of the Product Aggregation. The Product has a Category, but it does not know how to create or edit a Category.

Take this another example. Imagine the ShoppingCart class, it's an aggregate root and contains a list of Items. The ShoppingCart is responsible for adding/editing/removing the Items, in this case you won't need a Repository for the Item class.

Not sure by the way, I'm new to this just like you.

Answer 2

Placing something You don't know where to put into artificial services usually leads to anemic domain model.

I would go with first option. But need for entities without context of root is a sign that You might lack another root.