問題タブ [domain-events]

ドメインイベントについて詳しく調べていますが、履歴上の理由から、エンティティの更新を永続化するためのアドバイスが必要です。私の例では、ユーザーエンティティとサインインを扱います。

ですから、私がやっていることがあるところでは、UserオブジェクトLastLoginDateを更新し、歴史的な理由でユーザーがログインした日時をログに記録したいと思います。私の質問は、リポジトリとコンテキストの新しいインスタンスを作成して、ハンドラーに変更を保存するか、イベントに何かを渡すかです。これが私が今苦労していることです。

最近のプロジェクトでイベンティングを実装するのに苦労しています。

structuremap が適切にスキャンされ、EventHandler がアセンブルされ、追加されていることを確認しました。

ドメインからイベントを発生させる前に。のようなものDispatcher.RaiseEvent(new [domainEvent class](x,y,z));

とイベントが盛り上がります。コレクション内のイベントを収集しているデザインを変更する必要がありました

ドメインをリポジトリに保存した後、それを上げます

でも今

ObjectFactory.GetAllInstances<IHandle<TEvent>>() ハンドラーの数 0 を返します

私が見守っていれば

ObjectFactory.GetAllInstances<IHandle<DomainEventClass>>() ハンドラーのコレクションを適切に返します（現在、2つあり、2つのカウントを示しています）

...これは、実際の型ではなく型として発生するイベントと関係があると想定しておりIDomainEvent 、それが構造マップで解決するのを難しくしています。

この問題を解決するにはどうすればよいですか?

よろしく、

ザ マール

--

編集1：

struturemap コンテナーには、アセンブリからスキャンされたすべてのイベント ハンドラーが含まれていることを確認しました。

編集 2

この質問をもっと注目させる方法がわかりません。希望する結果を達成するためのソリューションに報奨金を追加しています。質問が明確でない場合は、質問してください。

基本的に、 typeのwhere is のObjectFactory.GetAllInstances<IHandle<TEvent>>()ハンドラーを返すようにします。発生するイベントは Collection に格納され、Domain が (サービス層から) 保存された後に発生します。TEventTEventIDomainEventIDomainEvent

IDomainEvent発生したイベントが実際にタイプであることを構造マップに知らせる方法があるはずだと考えていますDomainEvent

var eventsToRaise=ディーラー.EventsToRaise(); デバッグ ウィンドウからの情報の追加:

ディスパッチャ ウィンドウでイベントが発生した後

編集 3: eventToRaise は「DealerName Changed」および「DealerCommunicationChanged」と表示されますが、
typeof(TEvent) は Type を Domain.IDomainEvent として指定します。

（VSウォッチウィンドウが情報を取得している場所から）正しいタイプにキャストできるようになることが可能であれば、問題は解決される可能性があると思います

- - - 結果 - -

どちらのアプローチも機能しました。私は両方を私のチームの他の 2 人のメンバーにアプローチしましたが、私たちは反射なしの解決策が正しい答えとして選択されると感じました。

今日は、実装を変更してテストを行い、ソリューションにこのソリューションに関する問題があるかどうかを確認します。

リフレクションベースのソリューションも正しい答えであるため、賛成票を投じました。

私はDDDを初めて使用し、詳細情報を入手するために現在記事を読んでいます。記事の1つは、ドメインイベント（DE）に焦点を当てています。たとえば、電子メールの送信は、コードの実行中にいくつかの基準が満たされた後に発生するドメインイベントです。

コード例は、ドメインイベントを処理する1つの方法を示しており、その後にこの段落が続きます

上記のコードは通常のドメイン作業と同じトランザクション内の同じスレッドで実行されるため、SMTPやWebサービスの使用などのブロックアクティビティの実行は避ける必要があることに注意してください。代わりに、一方向のメッセージングを使用して、これらのブロッキングアクティビティを実行する他の何かと通信することをお勧めします。

私の質問は

1. これはDEを処理する際の一般的な問題ですか？それとも、言及された記事の解決策の懸念だけですか？
2. ドメインイベントがトランザクションで発生し、システムがそれらを同期的に処理しない場合、どのように処理する必要がありますか？
3. これらのイベントをシリアル化してスケジューラー（または他のメカニズム）に実行させることにした場合、トランザクションがロールバックされるとどうなりますか？（記事では、トランザクションで実行されたコードでイベントが発生します）誰がそれらをキャンセルしますか（データベースに永続化されていない場合）？

ありがとう

この記事では、「ドメイン イベント」と呼ばれる優れたパターンについて説明します: http://www.udidahan.com/2009/06/14/domain-events-salvation/

ただし、このパターンの大きな欠陥の 1 つが、ユーザー Andy によるコメント 27 で強調されています。トランザクションが失敗した場合、ドメイン イベントを実行したくありません。したがって、何らかのキューイングメカニズムを作成する必要があります。

残念ながら、これは、システムを簡素化するはずだった手法を大幅に複雑にするように思えます。

ドメインイベントのキューイングの良い例や議論、特にNHibernateとうまく統合されたソリューションを知っている人はいますか?

2つの集約ルートと1つの通常のエンティティの単純な例のドメインがあります。 Tenant、UserGroupおよびUserこの特定のサンプルのどこで、2つのAggregateRootsTenantを補います。User

UI /サービスレイヤーからコマンドを受信すると、書き込み専用ドメインを操作するコマンドハンドラーに到達します。

これはAggregateRootUserであるとはまったく考えられていませんが、他のユーザーから参照されるため、通常のエンティティにすることはできません。（はい？）

これらの2つのAggregateRootsは通信する必要があります。の制限付きコンテキスト内のエンティティである、にUser属さずにAを作成することはできません。おそらく、単純な制約であるため、コンストラクターを介してユーザーを作成できます。UserGroupTenantUser.Create(TenantId, UserGroupId)

DomainEvent（ユーザーの）with Date、AggregateVersion、およびAggregateIdを生成します。次に、ぼやけた部分に行きます。

このイベントをストアにコミットすると、このイベントはバス（メモリなど）にブロードキャストされます。これは、コマンドハンドラーと同様に、ドメインのイベントハンドラーが作成されたユーザーをキャッチし、通知/操作してTenant？UserGroupを追加するポイントUserIdです。

これを解決することについての私の考えは完全に間違った方向に進んでいますか？

私が見たすべての CQRS の例で、ドメイン イベントは読み取りモデルの更新をトリガーしますが、それ以外は何もしません。しかし、ドメイン イベントがドメイン内の他の変更を引き起こしたい場合はどうでしょうか?

たとえば、次の要件があるとします。

• 「口座を解約する」ボタンがクリックされた場合、口座を解約する
• 口座の支払いが完了したら、口座を閉鎖します
• アカウントが閉鎖されたら、アカウント所有者を「特別」としてマークします

これを処理する最良の方法は何ですか?

1. Account.Close() で AccountClosed イベントを作成し、所有者を「特別」としてマークします。
2. 所有者を「特別」としてマークする AccountClosed ハンドラーを作成する
3. MarkOwnerAsSpecial コマンドを送信する AccountClosed ハンドラーを作成する
4. アカウントを閉じるコマンド ハンドラーも、アカウント所有者を「特別」としてマークするようにします。

この記事で詳しく説明されているように、UdiDahanのドメインイベントパターンとインフラストラクチャの単純なJava実装を探しています。

それは非常に単純で、私は独自の解釈を実装しましたが、私はJavaの初心者であり、言語の経験が浅いために間違いに噛まれたくありません。

私が見つけた唯一のJava実装は、Jdon Frameworkにありますが、私のプロジェクトの現在の実装には少し重すぎます。

ありがとう！

記事に続いて：httpDomainEvents ： //www.udidahan.com/2009/06/14/domain-events-salvation/実装がDIコンテナを使用し ていることがわかります

その後

ドメインオブジェクトを格納するのと同じアセンブリ内にDIコンテナを統合する必要がありますか、それとも外部化/抽象化できますContainer.ResolveAll<Handles<T>>()か？（以前の経験では、すべてのDI-relatedものを中に入れましglobal.asax.csた）。

技術的にはNinjectDIコンテナにしか精通していませんが、おそらく概念を理解しているので、アドバイスやイラストをいただければ幸いです。

ありがとう！

CQRS とドメイン イベントの概念を使用したドメイン モデルでアプリケーションを構築しています (ただし、イベント ソーシングはなく、単純な古い SQL のみです)。SomethingChanged 系のイベントでは問題ありませんでした。次に、SomethingCreated イベントの実装に行き詰まりました。

ID主キーを持つテーブルにマップされるエンティティを作成すると、エンティティが永続化されるまでIDがわかりません。エンティティは永続性を無視するため、エンティティ内からイベントを発行する場合、ID は不明です。context.SaveChanges() を呼び出した後にのみ魔法のように設定されます。では、どのように/どこに/いつ Id をイベント データに入れることができますか?

私は考えていました：

• イベントにエンティティへの参照を含めます。これはドメイン内では機能しますが、イベント/メッセージによって通信する複数の自律システムを備えた分散環境では必ずしも機能しません。
• SaveChanges() をオーバーライドして、発行のためにキューに入れられたイベントを更新します。しかし、イベントは不変であることを意図しているため、これは非常に汚いようです。
• ID フィールドを取り除き、エンティティ コンストラクターで生成された GUID を使用します。これは最も簡単かもしれませんが、パフォーマンスが低下し、デバッグやクエリなどの他の作業が難しくなる可能性があります ( 、where id = 'B85E62C3-DC56-40C0-852A-49F759AC68FB'いいえなど)。これは、多くのサンプル アプリケーションで見られるものです。MINMAX
• ハイブリッド アプローチ - ID はそのままにして、主に外部キーとより高速な結合に使用しますが、アプリケーションのリポジトリからエンティティをプルする一意の識別子として GUID を使用します。

特定の状況で新しいドメインエンティティを追加することに関して、UdiDahanによって示されているドメインイベントパターンを理解しようとしています。

通常、エンティティを使用してそれらを作成し、リポジトリを介して追加します。私はまだこれを行うと思いますか？

私の例は、通常、システムにアセットを追加することです。このような：

ただし、アセットの作成は、結果として特定のプロセスを実行したいイベントです。したがって、ドメインイベントで処理できるため、これを行う必要がなくなったことが開発者から提案されました。

これで、createメソッドはイベントを発生させ、create eventハンドラーによって処理されます。このハンドラーは、基本的にイベントをリポジトリに挿入し、作成場所のウェアハウスマネージャーなどに電子メールを送信します。

ただし、アセットにcreateイベントがあることは、私にはかなりアクティブなレコードのように見えます。ただし、ドメインでは、新しいアセットが作成されることについて人々が話します。ですから、よくわかりませんでした。

考え？