Domain-Driven Design - Aggregates

As I go reading this excellent book, the more and more I have to recognize the greatness of this book in terms of its contents.

This chapter is very clear discussing a very hot topic which is how to encapsulate the invariants of a system.

I never really used this aggregate concept in my projects but the need for the very same solution became very clear in a recent project I am working on. There is always a heated debate in terms of if the invariants should be by entity, enforced on the database or even using the document model which is very close to aggregate as I understand, they might even be synonyms depending on who is talking about them.

The only point I am waiting for a better answer in the next chapters is related to the access of internal aggregate elements: According to Evans, they should be only accessible through the root aggregate entity, but I know many models where one entity from a clear aggregate points to another one on another aggregate. Lets say, details that have links to each other. I tend to think that those type of models might be wrong, and they probably are, but eventually as in the car parts example, one might want to tun a query to get all the cars where the tires needed to be rotated in order to send letters to the customer as a friendly reminder. I will keep on reading and see, I think.