Let's pretend I have an 'Book' entity, that can contain many 'Chapter' entities, having both their own unique IDs. A chapter must belong to a book, it cannot exists on its own (ie: there is a required foreign key in the chapter's table).
There is a screen where the chapter's content can be edited. So far, we considered books as aggregate roots, and everthing that was done on chapters was done through aggregates that had the parent book as root. All was great.
Suddenly, we get a requirement for the chapter editing screen, in which we need to add a dropdown list to be able of changing in which book we want the chapter to appear (from a list of account owned books), which breaks our current way of doing things.
How should I approach this? The application is SQL based, so being the relationship one-2-many, the operation is essentially changing the FK value in the chapter's table... but DDD wise, I believe it is more complex, since there may situations in which we need to update the book information (number of chapters, etc ... ). We work in transactional fashion, we cannot use eventual consistency for this.
Making a chapter an aggregate root itself?
Making a aggregate with a composite root between the current document and the one to where I want to assign the chapter to?