DDDとCRQSを使用する場合、コマンドごとにイベントを1つだけにする必要がありますか？

構成より規約を使用してdddアプリケーションを設計する方法を探しています。

集約「クライアント」に「FillProfile」と定義されたコマンドがあるとします。論理的に「ProfileFilled」イベントを発生させます。

コマンドがイベントよりも多く発生する場合、またはコマンドが何らかのロジックに基づいて異なるイベントを発生する場合がありますか？または、これは常に1対1の関係です（1つのコマンドは常に何も発生させないか、特定のタイプの単一のイベントを発生させます）。

これが事実である場合、コマンドが常に同じイベントを発生させるため、その事実に基づいてコンベンションシステムを構築できるため、これを求めています。「RaiseEvent」が「EventRaised」になることを知っています...

質問に「CQRS」というタグを付けたので、ここで説明するように、「CQRS＆Event Sourcing」コンテキストのイベントを意味すると思います。で、このチュートリアル、イベントとコマンドとの違いはよく説明されます。

• イベントは、システムの観点から、システム内の基本的な「発生する可能性のあるもの」をキャプチャします。

• コマンドは、ユーザーの観点から、ユーザーが操作と見なすものによって定義されます

そして、これにより、1対1の対応でコマンドとイベントがいくつか発生することがよくありますが、これらの異なる視点は、複数のイベントを起動するコマンド、またはコマンドパラメーターに応じて異なるイベントを発生させる可能性があります。コマンドがイベントをまったく発生させないケースも想像できますが、それは非常に例外的なケースであり、非常に典型的なケースではありません。

たとえば、チュートリアルではイベントに言及しています

• TabOpened
• 注文した飲み物
• 注文済み

およびコマンド

• OpenTab
• PlaceOrder

ここでは、コマンド「OpenTab」はイベント「TabOpened」につながりますが、コマンドPlaceOrderはイベント「DrinksOrdered」、「FoodOrdered」、またはその両方につながります。

実際、新しいシステムを「ゼロから」設計する場合は、コマンドとイベントを1対1で対応させて設計し、システムが大きくなったときにどれだけ拡張できるかを試してみてください。ハイブリッドアプローチを試すこともできます。イベントとコマンドのリストを1対1で対応させ、いくつかの追加のコマンドを組み合わせます。設計している特定のシステムにどれだけ導いてくれるか試してみてください。

通常、1つのコマンドが1つのイベントにつながります。しかし、場合によっては複数の場合もあり、実装に依存します。

コマンドが他のコマンドを呼び出し、それぞれが独自のイベントを起動します。または、コマンドが独自に異なるタスクを実行し、複数のイベントを発行します。例えば：

RegisterUserCommand

• User.create（メール、パスワード）→ UserCreatedEvent
• User.updateProfile（firstName、lastName、location）→ UserProfileUpdatedEvent
• User.joinDefaultGroup（）→ UserJoinedGroupEvent

1つのコマンドで複数のイベントを発生させることができます。それはただ一つの事実の論理的な結論です：Composite command存在します。

それぞれがイベントを発生させる2つのコマンドがあるとします。次に、これら2つの複合コマンドを作成します。複合コマンドを使用している人から見ると、コマンドが2つのイベントを発生させたように見えます。

したがって、複数のイベントを発生させる（またはまったく発生させない）単一のコマンドを持つことを妨げるものは何もありません。