別の集約から発行された集約のイベントを処理することは正しいですか？ドメインはコマンドのみを処理する必要がありますか？DDD、別の集約からイベントを集約できますか？
私の場合、私は設定を管理するアプリケーションを持っています。私はアプリケーション用の集約とapplicationGroup用の集計を持っています。特定のアプリケーショングループの設定を作成したい場合、コマンドは私のapplicationGroupによって処理され、次にapplicationGroupはイベントGroupSettingsCreatedを発行しますが、DDDはApplicationAggregateでこのイベントを直接処理できるとしますか？または、イベントハンドラでこのイベントを処理し、コマンドにマップしてからApplicationAggregateに送信する必要がありますか？
ジョン
おかげ
1つの集約のイベントを別の集約内で処理したい場合は、そのハンドラをイベントを生成する集約の子にする必要があります。
つまり、このbounded contextでは、Applicationは、ApplicationGroupの子であり、ApplicationGroup.CreateSettings()は、その子アプリケーションに設定を伝播する必要があります。
これを考える別の方法：「アプリケーショングループ」は本当の集約ではなく、むしろユーザーインターフェイスによって提供される利便性です。
興味深い、私はそれを試してみましょう。 – Gui
ジョンは、私はあなたの質問に話すDDDで何も知りません。これは実際にEvent Driven Architecture（EDA）とCommand Query Responsibility Segregation（CQRS）の質問です。
具体的なアドバイスを行うために、アプリケーションとアプリケーショングループのエンティティがどのような役割を果たしているかを知りたいと思います。ところで、彼らはドメイン概念よりもアプリケーション/インフラストラクチャの概念に似ています。
一般に、次のアクションがソースから論理的にプッシュされるコマンドを使用します（次のアクションは必要な次のステップです）。問題のアクションが論理的に上流の振る舞いに反応しているときにイベントを使用します（上流のコードは、この反応をちょうど起こったことに気付かない）。
こんにちは@Eric Farr、私のシナリオの精度を高めるために、「アプリケーション」を「アプリケーショングループ」に添付するときは、 「アプリケーショングループ」は、すべての現在の「設定」を 「アプリケーション」に送信する必要があります。つまり、アプリケーショングループ集合は、アプリケーション集合によって処理されるイベントを公開し、アプリケーション集合は設定を作成するためのイベントを公開します。この相互作用の問題は、イベントが別のイベントをトリガするということです。あなたが言ったように、イベントを送信するコマンドの役割です。 – Gui
これまで行ってきたことは、イベントを「アプリケーショングループ」集約からコマンドにマップし、それを「アプリケーション」集約に送信することです。必要なグルーコードの量（イベント=>マッピング=> コマンド）は、何かが間違っていると思います。私は@JeffのSternalの解決策を試みるつもりです – Gui
@ジョン、それは理にかなっています。私はその2つが別々のルーツであることを疑っていましたが、もっと知らないと言うのは難しいです。がんばろう！ –
私はそれに何も間違いを見ません。たとえば、私のモデルでは、契約書に署名したときに、支払い計画は自分自身を再計画すべきであることを知っています。これはもちろん、どの計画が対応すべきかを把握するための関連付けが必要です。 –