メッセージがコマンドメッセージかイベントメッセージかを判断する方法

2つのエンタープライズ統合パターンは、コマンドメッセージとイベントメッセージです。私は、他のシステムとの統合だけでなく、サービス間の内部通信にもメッセージングを使用するシステムに取り組んでいます。ことになって最終的に一貫性のあるシステム、およびサービスは、（カップル専用のサービスへの例外を除いて）お互いの無知ことになっています。そのため、リモートプロシージャコール（RPCまたはRPI）のように感じることは避けようとします。バスとメッセージ指向のミドルウェアシステムがあり、すべてのメッセージがブロードキャストされます。

私たちは、過去完了でフレーズとして、あるイベント、例えば、として私たちのメッセージに名前を付ける傾向がありますPurchaseOrderShipped。ただし、多くの場合、イベントは他のサービスがイベントについて知る必要がある場合にのみ追加され、最初は多くの場合1つのサービスのみが重要です。さらに、そのサービスは結果としてイベントを発行することがあり、そのイベントは最初のサービスでリッスンされます。したがって、相互作用を図にすると、イベントメッセージの図よりも上のリンクのコマンドメッセージの図（またはRPC図）のように見えますが、これは実際には実装されていませんダイレクトメッセージングですが、バスでブロードキャストします。それに加えて、コマンドとして名前が付けられたいくつかのメッセージが追加されたことを最近見たという事実、つまり、命令のフレーズ、例えばBillShippedPurchaseOrder。

奇妙なことに、メッセージの名前とその流れは、イベントとして命名されたかコマンドとして命名されたかによって変わりません。では、何かがコマンドメッセージかイベントかをどのように判断するのでしょうか？これはセマンティクスと命名の単なる違いですか、それともコマンドとイベントメッセージの実際の実装の違いはありますか？すべてのメッセージがブロードキャストされていることを考えると、それらのどれもが本当にコマンドメッセージではないということですか？

コマンドとイベントの間には微妙ですが、重要な違いがあります。コマンドは応答を前提としていますが、イベントは応答を前提としておらず、単なるステートメントです。

抽象度を低くするには：

ShipOrderはコマンドであり、送信者ShipOrderはおそらく何らかの応答を期待します。
OrderShippedは宣言であり、GoodJob!この例では役に立たない応答のように、送信者は応答を期待する可能性は低いです。

イベントメッセージのみを期待するようにシステムを設計している場合、メッセージを何と呼ぶか​​はシステム設計にとって必ずしも重要ではありません。 開発者はメッセージの名前に戸惑うかもしれませんが、システムはあなたが物事に名前を付けるためにどんな慣習に従うかに関わらず、うまく反応します。

しかし、仲間の開発者がイベントのみのメッセージモデルに従っているようには思えません。サービスが送信する「イベントメッセージ」に対する応答を期待している場合、実際にはコマンドメッセージを送信しています。それは大したことではなく、情報の要求などのコマンドが必要になる多くの場合を考えることができます。ただし、イベントメッセージのみが表示されると予想される場合は、セマンティックな頭痛の種になります。

メッセージのブロードキャストは、メッセージがコマンドであるかイベントであるかには実際には影響しません。一般的に、コマンドをブロードキャストすることは労力を重複させるためです。しかし、できなかったと言うことは何もありません。初期のネットワークプロトコルはすべてのパケットをブロードキャストし、受信者は無視するタイミングを把握するために十分にインテリジェントでなければなりませんでしたメッセージ それらに属していないパケット。

イベントメッセージは、発生したばかりのものです。あなたはちょうど起こった出来事を通知しています。

コマンドメッセージは、何かが行われることを期待するメッセージです。応答を期待する場合と期待しない場合があります。

結合に至るものをいつ使用するかは、システムが進化するにつれて時間の経過とともに変化します。コマンドよりもイベントを優先すると、結合が少なくなります。イベントのエミッターは、消費者を気にしません。コマンドパターンでは、呼び出し元が知っているため、プロバイダーの存在に依存しています。

Bill Pooleは、コマンドメッセージを一緒に避けることを提案しています：http : //bill-poole.blogspot.com.au/2008/04/avoid-command-messages.html

http://bill-poole.blogspot.com.au/