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

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. Someh开发者_JS百科ow 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?

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.

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.

Don't try to implement everything with your domain model. The domain model is powerful for changing the state of the system, but unnecessary complex for querying. So separate the two. It's called Command Query Responsibility Segregation, or CQRS. And no, it has nothing to do with Event Sourcing, even though they do work nicely together.

I implement scenarios such as this so that I have a domain logic side with the domain objects and repositories (if needed), which do the state changing when something happens, i.e. new order is placed or order is shipped. But when I just need to show something in the UI, for instance the list of the products filtered by the category, it is a simple query and does not involve the domain objects at all. It simply returns Data Transfer Objects (DTO) that do not contain any domain logic at all.