Supposing that both are aggregates, copy whatever author data you need into the Book aggregate upon adding the new book so that any subsequent commands have enough author data to work with. Now if the Author aggregate needs information about the books written by the author, then it could “subscribe” to the NewBookAdded event (technically you could send a RegisterAsAuthorOfBook command to the Author aggregate as a result of the NewBookAdded event). I presume one could model this the other way around as well, but I’m not that intimate with the Book Author domain.
Bottom line is that you don’t really store many-to-many because they don’t scale. You have to start thinking of them (aggregates) as sending messages to each other. The bigger question is what needs to be consistent and at what point in time does it need to be consistent. Do we care that the Author does not instantaneously reflect the fact a new Book has been added, of which she/he’s the author? Are there any invariants that Author wants to enforce with regard to the books he/she has written (and vice versa)?
Another thing is to stop being data oriented and more behavior oriented. What’s the behavior of the Book and Author aggregate? This will tell what data is required at which point and how it should be modelled.
http://pastie.org/1220582 for a first stab at the Book aggregate.