特定のドメインイベントに登録できるBounded Contextのリスナー数はいくつですか？

Question

私は、特定のドメインイベントに登録できるリスナーの数がどれほど多いかというベストな戦略については疑問があります。

新しいユーザーがBounded Context Aで作成されたときに、UserWasCreatedというドメインイベントが公開されているとします。次のような多くのタスクを実行する必要があるそのイベントにサブスクライブしたBounded Context Bがあるとします。電子メールを送信し、ユーザの特定の情報を持続させ、ユーザ情報を外部サービス（すなわちCRM）にプッシュする。

私の質問は、同じBounded Context内でそのイベントに必要なリスナーは何個ですか？

私はVernonのIDDDの本で、このようなイベントごとに1人のリスナーしかいないことが分かりました。UserWasCreatedListenerしかし、そのリスナーは私の例では異なるタスクが関与しているのに対し、特定の責任は1つだけです。

イベント・タスクごとに1つのリスナーを持つことは意味がありますか？たとえば、次のような例を考えてみましょう：

これらのリスナーの名前はどのようにしますか？あまりにも多くのリスナーを作成するためにスケーラビリティの問題はありますか？

Answer 1

短い答えは、直接イベントのためにそこにすることができますどのように多くのリスナー（加入者）に関連する：

• ドメイン：0 N

  に私は以下のタイプのイベントを区別したいです

• イベントソーシング
• メッセージング（システム）

異なる理由があり、多くの場合異なるデータを運ぶからです。

に戻るあなたはプロセスを記述しています。プロセスは通常、コマンドによって開始されます。または、場合によってはイベントのように開始されます。メッセージは、彼らは非常に反応あるを振り付けある場合

• オーケスト
• 振付

：プロセスは、2つの方法の上で駆動することができます。 1つのイベントが別のイベントにつながることを意味します。あなたのケースでは、あなたは持っている可能性があり：

• UserCreatedEvent - > PersistUserHandler（加入者） - > UserPersistedEvent
• UserPersistedEvent - > CrmListener（加入者） - > CrmUserCreatedEvent
• CrmUserCreatedEvent - > EMailNotifier（加入者） - > UserNotifiedEvent

これは、単純で連続的なフローであれば問題なく動作します。アイテムのレビューや並列処理など、ユーザの介入が必要な場合は、髪の毛がつく傾向があります。

Orchestraionは、一方で、プロセスの状態を維持し、様々なアトミックサービスと相互作用プロセスマネージャを利用します。

場合によっては、UserRegistrationProcessが必要な場合にインスタンス化される可能性があります。あなたの場合は、おそらくユーザーの作成。もう1つのアプローチは、プロセスを開始し、にユーザー作成を含めることです。 UserRegistrationProcessは、さまざまなイベントのサブスクライバになります。しかし、さまざまなリスナーの代わりにを任意のイベントに反応させると、関連するコマンドだけが処理されます。

• スタートプロセス
• プロセスCreatedUserCommand
UserEndpoint（BC）に処理が UserCreatedEvent
UserEndpoint（BC）からの処理が CreateCrmUserCommand
CrmEndpoint（BC）に処理が CrmUserCreatedEventの送受信を行う送受信しますCrmEndpoint（BC）から
• プロセスはSendEMailCommandをEMailEndpoint（インフラストラクチャ）に送信しますProcess receives the EMailSentEvent`はEMailEndpoint（インフラ）
• をfromt プロセス層は、それ自体で有界コンテキストとなる。このようにプロセス

を終了します。

オーケストレーションは、プロセスの進捗状況を常時把握しているので好きです。