Aggregate roots are a central concept in Domain Driven Design. The idea is pretty simple and refers to how certain entities or objects should only be manipulated (and retrieved) in the context of their root or parent (or ancestor etc.) entity.
If we are able to centralize the point at which any objects in an aggregate graph are edited to a single object (the aggregate root) we can enforce rules and validations to ensure the whole graph remains valid.
In eShopOnWeb the repository pattern helps enforce non manipulation of anything but aggregate root classes. We can see below in the order aggregate that only the Order class implements IAggregateRoot and thus is the only class from this aggregate allowed to create a strongly typed repository to deal with persistence.
Click on the image for a larger view in a new window…
Of course we should note there is nothing stopping a developer from having OrderItem (for example) implement the IAggregateRoot interface. In this case they could create a repository for the OrderItem class and therefore bypass any logic contained in the root… but… there’s only so much we can do on a code level to guide developers.
IMHO due to the clear folder structure (eg. BasketAggregate, BuyerAggregate and OrderAggregate) as well as the use the IAggregateRoot marker interface eShopOnWeb does a really good job of letting developers know certain objects shouldn’t be retrieved and edited directly.