如何确定消息是命令消息还是事件消息？

两种企业集成模式是命令消息和事件消息。我正在开发一个系统，在该系统中，我们不仅使用消息传递与其他系统集成，还使用服务之间的内部通信。它应该是一个最终一致的系统，并且服务应该彼此一无所知（几个特殊用途的服务除外）。因此，我们尽量避免感觉像是远程过程调用（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/