If Book aggregates Chapter which in turn aggregates Page, then what should be the aggregate root? One possibility might be:
Book is an aggregate root with Chapter as a leaf and Chapter is an aggregate with Page as a leaf.
In this scenario, Chapter is a leaf in one aggregate and a root in another. Is this okay? Would it make sense in this scenario to have two repositories, one for Book and another for Chapter? If so, then couldn’t the Chapter repository be used to circumvent the fact that access to Chapter should only happen via Book? What would be the best way to handle a situation like this?
In my opinion, the whole idea of aggregate roots make sense only when there is a single root for a given aggregate. Which one — it depends on your requirements. Let’s examine two possibilities:
Book is a root and it contains Chapters containing Pages. This design is useful when your usage scenarios all include interacting with books: users select books and apply their operations/commands on whole books. Notice, that the Book aggregate is in ‘operations’ layer of your domain model — it, as a whole, represents concepts what part of are day-to-day business.
Chapter is the root. Is contains Pages. It also has reference to Book. This design is useful when usage scenarios focus on interacting with individual chapters. Chapter aggregate is in ‘operations’ layer now. Book forms an aggregate by itself but is is placed in ‘potencial/capabilities’ layer beneath the operations layer. This means that books are an asset to the organization, an enabler for the business, but are not part of day-to-day activities. Moreover, books don’t know anything about being referenced by Chapters.
To sum up, all depends on specifics of you case, the requirements you have. Be aware that layers in the domain model ore primarily a business concept, not technical one — they hep you to model the domain well. For further information please read Eric Evans’ Domain-Driven Design, especially ‘Large scale structure’ part.