CQRSとの多面的な関係の代替案

Question

CQRS/DDDとの古典的な多くの関係をどのようにモデル化しますか？

DDDとCQRSの両方の実装とソリューションの両方がドメイン固有の傾向があることを知っているため、この質問に対する一般的な答えを考案することは難しいかもしれません。

しかし、私たちは馴染みのある関係があると仮定しましょう 本 と 著者. 。これは古典的な多くの関係です。

私には、最も自然なことです 本 と 著者 2つの異なるものです エンティティ それぞれが自分自身に属していること 集計ルート. 。したがって、それらの間の多くの関係を明示的にモデル化することは、行く方法ではありません。

AddbookCommandをどのようにモデル化しますか？私たちは私たちの図書館に本を追加できるようにしたいと思っています。 著者 これを書いた 本. 。そのような関係をどのようにモデル化（そして持続する）のでしょうか？

ない 本 または 著者 良い候補者のようです 値オブジェクト...

Answer 1

両方が集合体であると仮定すると、新しい本を追加すると、書籍に必要な著者データをすべてコピーして、後続のコマンドが操作するのに十分な著者データを持っているようにコピーします。著者の集計が著者によって書かれた本に関する情報が必要な場合、NewBookaddedイベントに「サブスクライブ」することができます（技術的には、NewBookAddedイベントの結果としてregisterasauthorofbookコマンドを著者の集約に送信できます）。私もこれを逆にモデル化できると思いますが、私は本の著者ドメインとそれほど親密ではありません。

結論は、スケーリングしないため、多くの人から多くのものを保存しないということです。あなたはそれら（集合体）を互いに送信すると考え始めなければなりません。より大きな疑問は、何が一貫している必要があるか、そしてどの時点で一貫性がある必要があるかということです。著者が新しい本が追加されたという事実を即座に反映していないことを気にしますか？著者が彼/彼女が書いた本に関して実施したいというinvaryantsはありますか（そしてその逆も同様です）。

別のことは、データ指向であり、より多くの行動指向であることをやめることです。本と著者の集計の行動は何ですか？これにより、どのデータが必要なのか、どのようにモデル化されるべきかがわかります。

http://pastie.org/1220582 本の集合体での最初の刺し傷について。