13

CQRS は私を思考モードにさせてくれました。私は CQRS のアイデアで新しいプロジェクトを始めようとしています。私が気に入っている主な点は、
1) クエリとコマンドの分離です。私たちのドメイン クエリは問題でした。
2) 監査用の Event Storage の使用 - 再生用には使用しません - 少なくとも今は。

クエリ側は得意ですが、ドメイン イベントについてはまだいくつか質問があります。

コマンドが複数の集約ルート (例: Order および OrderDetail) の更新をもたらす場合、それらを UnitofWork (トランザクション) の下でスコープします。現在、各ドメインは、その状態が変更されたときにイベントを発行する責任があります。

コマンドが 3 つの orderDetail レコードを変更するとします。各 OrderDetail は 2 つのイベントを公開します。最終的に 6 つのイベントがあります。

a) ドメイン オブジェクトに変更を加えた直後にイベントを発行する場合 (ただし、トランザクションをコミットしていない場合)、発行された (サブスクライバーによって消費された可能性がある) イベントを元に戻すにはどうすればよいですか?

  • 私が考えることができるのは、公開されるイベントを「同じ作業単位のスコープの下で」リストに保持し、トランザクションのコミットが呼び出されたら、それを保存して公開することです。これは人がすることのように聞こえますか。

b) OrderDetail の変更により、Order Aggregate ルートでも何らかの変更が行われる必要がある場合、
i) OrderDetail Aggregate によって公開されたイベントを処理することによって、これらの変更を行う必要がありますか? たとえば。2 つの注文明細が削除されたとします。これにより、注文ステータスが「優先」から「非優先」になります。ii) イベントでエラーが発生し、注文状態が更新されない場合 - 注文が引き続き優先される場合、2 日以内に発送されます。

別の質問を追加
c) 「ドメイン イベントは、すべてのアプリケーション状態変更のソース」ですか、それとも「すべてのアプリケーション状態変更の結果」ですか?

前もって感謝します、

ザ マール

4

1 に答える 1

10

a) you should not publish events until your transaction is commited, an event reprsent something that has happened, and hence the reason why they are all named in pass tense (eg OrderClearedEvent). Also in the case that you have to "revert" an event, you should take a corrective action, ie you dont erase the event, you must trigger a new event that corrects the effects of the event you want to revert

b) it seems that this is more of a problem on how you are modelling you entities and commands that anything else. I cant think of a reason why OrderDetail would be an AggregateRoot, but I dont know your domain...

c) Commands will result in at least one event being published

Hope this helps :) As Rinat said, the google group is the best place for asking questions, also have a look at cqrsinfo.com and the sample code from github.com/MarkNijhof/Fohjin and github.com/gregoryyoung/m-r

于 2010-10-18T16:10:02.603 に答える