8

ドメインイベントを実装する場合、イベントハンドラーは、純粋にドメインの問題にのみ使用する必要があります。あなたがビジネスの専門家と話し合う何か、またはそれらはドメインモデルに興味を持っている何かによって使用されるために開かれていますか？

これはおそらく簡単な例で最もよく説明されます。従業員に仕事をスケジュールするためのカレンダーアプリケーションを考えてみましょう。

次のドメインイベントが発生する可能性があります...

AppointmentAdded AppointmentRemoved AppointmentContentChanged AppointmentMoved

これらのイベントのハンドラーがあります。たとえば、予定が従業員の勤務時間外の時間に移動された場合、警告フラグを設定します。

もちろん、これらのイベントに関心のあるアプリケーションの懸念事項があります。たとえば、予定がカレンダーに追加された場合、後で変更をコミットできるように、それを作業単位に追加する必要があります。

これらのアプリケーションの懸念はドメインイベントの利用者である必要がありますか、それとも代わりに個別のシステムイベントを発生させて処理する必要がありますか？

4

2 に答える 2

5

DDD ソリューションでイベントを使用するには、確立された方法が 2 つあります。

最初のものは、イベントに関する Udi Dahan の記事に基づいています。まだ読んでいない場合は、強くお勧めします。要約すると、通常の ORM スタイルの動作に加えて、静的クラスを使用してイベントを発行することを示しています。したがって、顧客の注文コレクションに注文を追加し、イベントを公開します。ドメインの動作はトランザクション スコープ内で実行されるため、イベント ハンドラーもトランザクション スコープ内で実行されます。また、オブジェクトを作業単位に手動でアタッチしないようにというアドバイスもあります。新しい集約ルートは、既存の動作を呼び出して作成する必要があります。

Greg Young によって推進されている別のオプションがあります。これは、基本的に状態を永続化する手段としてイベントを使用するイベント ソーシングに基づいています。このアプローチでは、集約ルートは通常、いくつかのインフラストラクチャ (基本集約ルート クラスなど) を使用してイベントを適用します。適用は、集約ルート クラスでイベント ハンドラーを呼び出し、このイベントをバス (使用するバスの実装に関係なく) に発行します。

于 2011-01-14T20:11:38.623 に答える
2

分野横断的な懸念を意味する場合は、アプリケーション ロジックが必要とする場合にとにかくそれを使用することを余儀なくされます。そのため、他のイベント処理コードと混在します。

ただし、ドメイン イベントが発生したときに複数の独立した処理を行う必要がある場合は、個別のイベント ハンドラーを使用することをお勧めします (関心の分離の原則を参照)。

ちなみに、最初のケースでは、ドメイン ロジックとイベント処理 (インフラストラクチャ) ロジックを混在させないようにしてください。ドメイン メソッドを呼び出すイベント ハンドラ内の左のインフラストラクチャ/分野横断的な懸念コード。ドメイン オブジェクトのメソッド内にドメイン コードを移動します。

于 2011-01-11T08:22:32.917 に答える