問題タブ [domain-events]

ドメインイベントと合わせてドメイン駆動設計について勉強しています。私は、これらのイベントが提供する懸念事項の分離が本当に気に入っています。ドメイン オブジェクトの永続化とドメイン イベントの発生の順序で問題が発生しました。ドメイン オブジェクトでイベントを発生させたいと考えていますが、永続性を考慮しないようにしたいと考えています。

ShoppingCartServiceこのCheckoutメソッドを使用して、基本的な を作成しました。

この例では、のコンストラクターは、特定のハンドラーによって処理できるイベントを発生させますOrder。OrderCreatedただし、エンティティがまだ永続化されていない場合、または永続化が何らかの形で失敗した場合に、これらのイベントが発生することは望ましくありません。

この問題を解決するために、私はいくつかの解決策を考え出しました:

1. サービスでイベントを発生させます。

ドメイン オブジェクトでイベントを発生させる代わりに、サービスでイベントを発生させることができます。この場合、CheckoutメソッドはOrderCreatedイベントを発生させます。このアプローチの欠点の 1 つは、Orderドメイン オブジェクトを見ると、どのイベントがどのメソッドによって発生したかが明確でないことです。また、開発者は、注文が別の場所で作成されたときにイベントを発生させることを覚えておく必要があります。気分が悪い。

---

2. ドメイン イベントをキューに入れる

もう 1 つのオプションは、ドメイン イベントをキューに入れ、永続化が成功したときに発生させることです。usingこれは、たとえば次のステートメントで実現できます。

QueueEvents<T>メソッドはブール値を に設定しtrue、メソッドDomainEvents.Raise<T>はイベントを直接実行するのではなくキューに入れます。の破棄コールバックでQueueEvent<T>は、キューに入れられたイベントが実行され、永続化が既に行われていることが確認されます。これはややこしいようで、ドメイン オブジェクトでどのイベントが発生しているかをサービスが認識できるようにする必要がありました。私が提供した例では、発生するイベントの 1 つのタイプのみをサポートしていますが、これは回避できます。

---

3. ドメイン イベントに永続化する

ドメイン イベントを使用してオブジェクトを永続化できます。オブジェクトを永続化するイベント ハンドラーを最初に実行する必要があるという事実を除いて、これは問題ないように思えますが、ドメイン イベントは特定の実行順序に依存してはならないことをどこかで読みました。おそらくそれはそれほど重要ではなく、ドメイン イベントはハンドラーがどの順序で実行されるべきかをどうにかして知ることができます。例: ドメイン イベントハンドラーを定義するインターフェイスがあるとします。実装は次のようになります。

イベント ハンドラーを使用して永続化を処理したい場合は、同じインターフェイスから派生する別のハンドラーを作成します。

現在NotifyCustomer、動作はデータベースに保存されている順序に依存するため、PersistOrderイベント ハンドラーを最初に実行する必要があります。これらのハンドラーが、たとえば実行順序を示すプロパティを導入することは許容されますか? メソッドの実装からのスナップDomainEvents.Raise<OrderCreated>():

---

私の質問は、他に選択肢はありますか？何か不足していますか？そして、私が提案した解決策についてどう思いますか?

Udi Dahan の Domain Events - Salvation articleで規定されているように、ドメイン イベントを実装しました。

私が理解している限りでは、ドメイン イベントは、発生元のスレッド (通常はドメイン モデルまたはサービス) に対して非同期で実行できます。

何らかの「共有」作業単位やリポジトリ実装は必要なく、トランザクションの一貫性も必要ありません。

質問: Udi が別のスレッドでドメイン イベントの処理を実装していないのはなぜですか?

たとえば、Taskイベントを非同期に処理するために の作成を追加しました。

これから発生する可能性のあるマルチスレッドの問題はありますか?

編集: これらのドメイン イベントは軽量ですが、これは MVC Web プロジェクトであるため、IIS で引き続き実行されることに注意してください。

ドメイン イベント パターンとこの投稿を考慮して、トランザクション モデルごとに 1 つの集計を保持することを人々が推奨するのはなぜでしょうか? 1 つの集計が別の集計の状態を変更できる場合があります。集約を削除 (またはその ID を変更) しても、それを参照する他の集約の状態が変更されます。集約ごとに 1 つのトランザクションを維持するとスケーラビリティーが向上する (サーバーごとに 1 つの集約を維持する) と言う人もいます。しかし、この種の考え方は、DDD の基本的な特徴であるテクノロジにとらわれないという特徴を壊しているのではないでしょうか。

したがって、上記のステートメントとあなたの経験に基づいて、他の集計の変更につながる集計、ドメインイベントを設計するのは悪いことですか?これにより、トランザクションごとに2つ以上の集計が行われます(例: 新しい注文が行われたとき) 100 個のアイテムを使用すると、顧客の状態が通常から VIP に変わります)?

ドメイン イベントは、イベント クラス、またはクラスとトピックに従ってディスパッチする必要がありますか?

たとえば、次のイベントがあります。

そしてイベントマネージャー、

Udi Dahanは、イベントはファースト クラス オブジェクトであると提案していますが、私はそれが気に入っています。UserRegisteredEventオブジェクト、 OrderCompleteオブジェクトがあります。私の質問は、型自体がイベント ハンドラーにバインドされるかどうかです。たとえば、イベント オブジェクトを publish メソッドに渡すだけでよいでしょうか?

これは、各ハンドラーが 1 つのクラス タイプにバインドされていることを意味し、制限があるようです。YAGNI は正しいかもしれませんが、以下はより強力ではありません。

これにより、イベントトピックがハンドラーのバインド先になります。このようにして、ハンドラーは継承の恩恵を受けることができます。型の安全性またはユビキタス言語の使用が問題である場合、次のことができます。

これは、より長い公開バージョンへの簡単な方法です。これは、新しいイベントごとにクラスを変更する必要があることを意味するため、少し面倒です。これは不要に思えます (実際、上記の方法を使用する場合は必要ありません)。

イベントがトピックのないクラスとして公開されるのを見たことがありますが、これは制限ですか、それともこれで問題が発生した人はいますか?

AR1 と AR2 という 2 つの集約ルートがあります。AR1 は、AR2 のインスタンスへの参照 (ID) のコレクションを保持します。AR1 メソッドの 1 つの中でドメイン イベントが発生し、AR2 インスタンスのコレクションが更新されます。ここで説明されている手法を使用してトランザクションが完了した後、ドメイン イベントが発生します。

私の問題は次のとおりです。AR2 を更新するためにドメイン イベントから呼び出しているメソッドは、現在、ドメイン イベントがアプリケーション サービス レイヤー (ビジネス ロジック レイヤーとは異なるアセンブリ) で実行されているため、公開されています (内部にすることはできません)。このメソッドをドメイン イベントで実行するだけで、他には何も実行したくありません。

どうすればこれを行うことができますか？

トランザクションの完了後にドメイン イベントを発行したいと考えていました。だから私はこの記事をここでフォローしました: http://www.jayway.com/2013/06/20/dont-publish-domain-events-return-them/また、このSOの投稿も見ました:イベントを発生させるドメイン メソッドへのリポジトリ

理にかなっています...しかし、インターフェイスコレクションを具象型に解決する方法について混乱しています。たとえば、IEvent のコレクションには、おそらく 2 ～ 3 種類のイベントがあります。正しいハンドラーを起動するために追加されたイベントを特定するにはどうすればよいですか?