2

One key difference often highlighted between Events and Commands in EDA is as follows:

Events are something which has happened

Commands are requests for something which might happen

What I can't understand is why implementations often use both of these together, when one always seems to be redundant? For example when we need to check if a customer has enough credit in order to complete an order, we can achieve this purely with events:

enter image description here

There are no commands on this diagram whatsoever. But in this article, it's suggested there are commands created in addition to the events behind the scenes:

enter image description here

What is the benefit of also including Commands here, doesn't it just add complexity? And which of the two is the Customer Service actually subscribing to, the CreatePendingOrderCommand, or the OrderCreatedEvent? Surely only one of these is acted upon by the Customer Service?

FBryant87
  • 4,273
  • 2
  • 44
  • 72

2 Answers2

4

What I can't understand is why implementations often use both of these together, when one always seems to be redundant?

In general, they aren't quite the same thing; it's only in the simple cases that the information is redundant.

"Commands" a something akin to proposals: they are messages that we send toward some authority to effect some change. "Events" are messages being sent from some authority.

Commands deliver new information to an authority. Events describe how information has been integrated with what was known before.

Events describe information that will be available when processing future commands - the information is durable; commands are transient.

Commands are often generated from a stale non-authoritive snapshot of some information (a report, or a "view"). Events are reflections of the state of the authority itself.

Events fan out from an authority; we know the sender, but not necessarily the receiver. Commands fan into an authority, we know the receiver, but not necessarily the sender.

It is pretty squishy. We are making copies of a data structure, and at some point our perspective shifts, and even though the source data structure is an event, the copy is a command.

Think subscription: the system is going to copy a data structure from my output stream (an event) to your input stream (a command).

My suggestion: it's all just "messages". Allow yourself to leave it there until you have more laps under your belt.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
-1

I would say

"A command can emit any number of events."

"Commands can be rejected."

"Events have happened."

cool
  • 1,746
  • 1
  • 14
  • 15