Альтернативы отношениям "многие ко многим" с CQRS

Как мы моделируем классические отношения "многие ко многим" с CQRS/DDD?

Я знаю, что реализация и решения DDD и CQRS имеют тенденцию к доменной специфике, поэтому может возникнуть сложный вопрос с общим ответом на этот вопрос.

Однако предположим, что у нас есть знакомые отношения между Книгой и Автором. Это классическое отношение "многие ко многим" .

Для меня кажется наиболее естественным, что Book и Author - это две разные Entities, каждая из которых принадлежит своему собственному Aggregate Root. Таким образом, явное моделирование отношения "многие ко многим" между ними - это не путь.

Как мы моделируем AddBookCommand? Мы хотим иметь возможность добавить книгу в нашу библиотеку, а также как-то заявить, что конкретный автор написал эту книгу. Как мы моделируем (и сохраняем) такие отношения?

Ни книга, ни автор не кажутся хорошими кандидатами на Объекты Value...

Ответ 1

Предположим, что оба являются агрегатами, скопируйте все данные автора, которые вам нужны, в агрегат книги при добавлении новой книги, чтобы любые последующие команды имели достаточное количество авторских данных для работы. Теперь, если сборщику Author требуется информация о книгах, написанных автором, он может "подписаться" на событие NewBookAdded (технически вы можете отправить команду RegisterAsAuthorOfBook в агрегат Author в результате события NewBookAdded). Я предполагаю, что можно смоделировать это и наоборот, но я не настолько интимный с доменом Book Author.

Нижняя строка заключается в том, что вы действительно не храните много-ко-многим, потому что они не масштабируются. Вы должны начать думать о них (агрегатах) как отправке сообщений друг другу. Более важный вопрос заключается в том, что должно быть последовательным и в какой момент времени оно должно быть последовательным. Неужели мы заботимся о том, что автор не мгновенно отражает тот факт, что добавлена новая Книга, автором которой он/она является? Существуют ли какие-либо инварианты, которые автор хочет применить в отношении книг, которые он написал (и наоборот)?

Другое дело - перестать быть ориентированным на данные и более ориентированным на поведение. Каково поведение агрегатора книг и авторов? Это покажет, какие данные требуются в какой момент и как это должно быть смоделировано.

http://pastie.org/1220582 для первого удара в агрегате книги.