タグ付けされた質問 「event」

私は最近、一見些細な建築上の問題に直面しました。私のコードには、次のように呼ばれるシンプルなリポジトリがありました（コードはC＃です）： var user = /* create user somehow */; _userRepository.Add(user); /* do some other stuff*/ _userRepository.SaveChanges(); SaveChanges データベースへの変更をコミットするシンプルなラッパーでした： void SaveChanges() { _dataContext.SaveChanges(); _logger.Log("User DB updated: " + someImportantInfo); } その後、しばらくして、システムでユーザーが作成されるたびに電子メール通知を送信する新しいロジックを実装する必要がありました。システムへの呼び出し_userRepository.Add()とSaveChangesシステムの呼び出しが多数あったため、次のSaveChangesように更新することにしました。 void SaveChanges() { _dataContext.SaveChanges(); _logger.Log("User DB updated: " + someImportantInfo); foreach (var newUser in dataContext.GetAddedUsers()) { _eventService.RaiseEvent(new UserCreatedEvent(newUser )) } …

40 architecture  single-responsibility  event 

API Gatewayパターンに従ってREST APIを介して機能を公開するマイクロサービスがたくさんあります。これらのマイクロサービスはSpring Bootアプリケーションなので、Spring AMQPを使用して、これらのマイクロサービス間でRPCスタイルの同期通信を実現しています。これまでのところ物事は順調に進んでいます。ただし、イベント駆動型のマイクロサービスアーキテクチャについて詳しく読んで、Spring Cloud Streamなどのプロジェクトを見ると、RPC同期アプローチで間違った方法で物事をしている可能性があると確信するようになります（特に、これをスケーリングする必要があるため）クライアントアプリケーションからの1秒あたり数百または数千のリクエストに応答するため）。 イベント駆動型アーキテクチャの背後にあるポイントを理解しています。私がよく理解していないのは、すべての要求に対する応答を期待するモデル（REST）の後ろに座っているときに、そのようなパターンを実際に使用する方法です。たとえば、APIゲートウェイをマイクロサービスとして使用し、ユーザーを保存および管理する別のマイクロサービスがあるGET /users/1場合、純粋にイベント駆動型のようにモデル化するにはどうすればよいですか？

16 spring  asynchronous-programming  microservices  event 

ドメインイベントハンドラーをDDDに配置するのに適したレイヤーはどれかという意見を教えてください。たとえば、新しい契約を追加するアプリケーションサービスがあり、契約が追加されたときに連絡先に電子メール通知を送信したいので、その電子メール送信者（ContractAddedイベントを処理する）アプリケーションサービスまたはドメインサービスまたは他に何か？

13 domain-driven-design  event 

2つのエンタープライズ統合パターンは、コマンドメッセージとイベントメッセージです。私は、他のシステムとの統合だけでなく、サービス間の内部通信にもメッセージングを使用するシステムに取り組んでいます。ことになって最終的に一貫性のあるシステム、およびサービスは、（カップル専用のサービスへの例外を除いて）お互いの無知ことになっています。そのため、リモートプロシージャコール（RPCまたはRPI）のように感じることは避けようとします。バスとメッセージ指向のミドルウェアシステムがあり、すべてのメッセージがブロードキャストされます。 私たちは、過去完了でフレーズとして、あるイベント、例えば、として私たちのメッセージに名前を付ける傾向がありますPurchaseOrderShipped。ただし、多くの場合、イベントは他のサービスがイベントについて知る必要がある場合にのみ追加され、最初は多くの場合1つのサービスのみが重要です。さらに、そのサービスは結果としてイベントを発行することがあり、そのイベントは最初のサービスでリッスンされます。したがって、相互作用を図にすると、イベントメッセージの図よりも上のリンクのコマンドメッセージの図（またはRPC図）のように見えますが、これは実際には実装されていませんダイレクトメッセージングですが、バスでブロードキャストします。それに加えて、コマンドとして名前が付けられたいくつかのメッセージが追加されたことを最近見たという事実、つまり、命令のフレーズ、例えばBillShippedPurchaseOrder。 奇妙なことに、メッセージの名前とその流れは、イベントとして命名されたかコマンドとして命名されたかによって変わりません。では、何かがコマンドメッセージかイベントかをどのように判断するのでしょうか？これはセマンティクスと命名の単なる違いですか、それともコマンドとイベントメッセージの実際の実装の違いはありますか？すべてのメッセージがブロードキャストされていることを考えると、それらのどれもが本当にコマンドメッセージではないということですか？

11 enterprise-architecture  messaging  event  command-message 

C＃でイベントをプログラミングするときは、次の形式でデリゲートを作成することをお勧めします。 delegate XEventHandler(object sender, XEventArgs e); 私の質問は、デリゲートの最初の引数ですobject sender。常にジェネリックである必要がありobjectますか？タイプの送信者があると、object常に次のようなコードになります。 val = ((ConcreteType)sender).Property; または、さらに詳細な、 ConcreteType obj = sender as ConcreteType if (obj != null) { ... } 強く型付けされた送信者に対する1つの議論は、他のオブジェクトが型を気にすることなくイベントを転送できることです。これはGUI環境では理にかなっているかもしれませんが、GUI以外でもメリットがあるかどうかはわかりません。 送信者のクラスが常に（少なくとも抽象クラスとして）わかっている場合はどうなりますか？私は実装していますたとえば、ListChanged抽象的にイベントをListクラス、および他のクラスは、（例えば、それを継承しようとしている場合はLinkedList、ArrayList）、それはタイプの送信者と私のデリゲートを定義するために、すべての権利でありますかList？ delegate ListChangedEventHander(List sender, ListChangedEventArgs e); または、従来型object senderをより具体的なタイプに変更することの欠点はありますか？

10 c#  event 

通常、イベントリスナーは、それらを登録したオブジェクトよりも長く存続するべきではありません。 それは、イベントリスナーがデフォルトで弱参照によって保持されるべきであることを意味しますか（オブジェクトリスナーが登録されている弱コレクションに格納されます）？ リスナーがその作成者よりも長生きする必要がある有効なケースはありますか？ それとも、そのような状況は間違いであり、許可されるべきではないのですか？

9 api-design  event