메시지가 명령 메시지인지 아니면 이벤트 메시지인지 결정하는 방법은 무엇입니까?

두 가지 엔터프라이즈 통합 패턴은 명령 메시지 와 이벤트 메시지 입니다. 다른 시스템과의 통합뿐만 아니라 서비스 간의 내부 통신을 위해 메시징을 사용하는 시스템에서 작업하고 있습니다. 그것은 궁극적으로 일관된 시스템 이어야하고 , 서비스는 서로에 대해 무지해야합니다 (몇 가지 특수 목적 서비스 제외). 따라서 원격 프로 시저 호출 (RPC 또는 RPI) 과 같은 느낌을 피하려고합니다 . 우리는 버스와 메시지 지향 미들웨어 시스템을 가지고 있으며 모든 메시지가 방송됩니다.

우리는 메시지를 사건으로, 즉 과거에 완벽하게 표현 된 문구로 부르는 경향이 PurchaseOrderShipped있습니다. 그러나 이벤트는 종종 다른 서비스가 알아야 할 경우에만 추가되며 처음에는 종종 하나의 서비스 만 처리합니다. 또한 때때로 해당 서비스에서 이벤트가 발생하여 첫 번째 서비스에서 청취합니다. 따라서 상호 작용을 다이어그램으로 만들면 위의 링크에서 명령 메시지에 대한 다이어그램 (또는 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/