CQRS / DDDとの古典的な多対多の関係をどのようにモデル化するのですか？
DDDとCQRSの両方の実装とソリューションはドメイン固有である傾向があることを私は知っているので、この質問に対する一般的な答えを思い付くのは難しいかもしれません。
ただし、 BookとAuthorの間に馴染みのある関係があると仮定しましょう。これは古典的な多対多の関係です。
私には、BookとAuthorがそれぞれ独自のAggregateRootに属する2つの異なるエンティティであることが最も自然に思えます。したがって、それらの間の多対多の関係を明示的にモデル化することは、進むべき道ではありません。
AddBookCommandをどのようにモデル化しますか？ライブラリに本を追加できるようにしたいのですが、特定の著者がこの本を書いたとどういうわけか述べています。このような関係をどのようにモデル化（および永続化）しますか？
BookもAuthorもValueObjectsの良い候補ではないようです...
両方が集約であると仮定すると、新しい本を追加するときに必要な著者データを Book 集約にコピーして、後続のコマンドで作業するのに十分な著者データが得られるようにします。Author 集約が著者によって書かれた書籍に関する情報を必要とする場合は、NewBookAdded イベントに「サブスクライブ」できます (技術的には、NewBookAdded イベントの結果として、RegisterAsAuthorOfBook コマンドを Author 集約に送信できます)。これを逆の方法でモデル化することもできると思いますが、私は本の著者のドメインにはあまり詳しくありません。
要するに、多対多はスケーリングしないため、実際には保存しないということです。それら (集合体) を互いにメッセージを送信するものとして考え始める必要があります。より大きな問題は、何を一貫させる必要があるか、またどの時点で一貫させる必要があるかということです。著者が、自分が著者である新しい本が追加されたという事実を即座に反映しないことを気にしますか? 著者が書いた本に関して強制したい不変条件はありますか (逆もまた同様です)。
もう 1 つのことは、データ指向や行動指向をやめることです。Book and Author 集計の動作は何ですか? これにより、どの時点でどのデータが必要で、どのようにモデル化する必要があるかがわかります。
http://pastie.org/1220582 Book 集計での最初の刺し傷。