Command Event: Align more closely with EIP terminology

[ylorph]

Changed the content of the pattern to follow the EIP classification of message types more closely while adhering as much as possible to the style guide (Prefer the term Event over Message or Record)

Renamed command-event.md to command.md : following the same naming convention as event.md

Description

https://github.com/confluentinc/event-streaming-patterns/issues/257

[benstopford]

Firstly, thank you for your contribution. I really appreciate this.

The tricky part with this proposal is a Command is broadly understood in the developer community as something that has a return value. In fact the terminology in this area is rather unfortunate.

A Command Event is supposed to imply the use of an event to trigger function rather than the use of an event for 'event carried state transfer'. Command is not a good name on its own as for many users it implies the content of some return value rather than the implied success that comes with reliable async messaging.

Command Message is another option, but that seems a poor choice as it's actually an event.

I do think this pattern could be clearer and in this regard though as I totally get the confusion here, but the common connotation of command, stemming back to Bertrand Meyer’s CQS (Command Query Separation) principle, causes confusion.

We should at least address this.

[ylorph]

Hi @benstopford , Thanks for the feedback. I totally agree that naming in this case is rather difficult.

Command is broadly understood in the developer community as something that has a return value

Well, at least for me , a command is a declaration of intent, a request to have some piece of data changed. and does not necessarely have a return value . They can definitvely be rejected by the system when some business rule / invariant is violated . As well as for technical reason. While an event is a statement of a fact , and can never be rejected by the handlers ( except for technical reasons)

I do think this pattern could be clearer and in this regard though

I believe I understand what you mean: the last section of the pattern does address that (https://github.com/confluentinc/event-streaming-patterns/pull/258/files#diff-febc837b377544514011415a69f8cd3ab5df1efec6c2647af222e0b2b209141cL112)

[ylorph]

Suggestion : Maybe describe the pattern as it's intended in the EIP more shortly . And then have a bigger one that is really based on events as intended and in use in today's EDA based sytems. So instead of changing the meaning of the original messaging pattern and the terminology, you can actuially add a new one . and this would leave the confusion behind

[alexlawrence]

The tricky part with this proposal is a Command is broadly understood in the developer community as something that has a return value. In fact the terminology in this area is rather unfortunate.

Command is not a good name on its own as for many users it implies the content of some return value

Which developer community understands a Command as something that has a return value?

Everyone I know (about) in the CQRS/ES community sees a Command as something that does not have a return value (in contrast to a Query). Sure, there may be an operational status or an ACK, but I wouldn't consider this a return value. Also, many people understand it similarly in the context of a distributed system (or "Microservices").

Commands are instructions to do something that are targeted at one specific receiver and they can be accepted or rejected.

Command Message is another option, but that seems a poor choice as it's actually an event.

I agree that you could view a particular message as an event. You could say that a "Command Event" is a fact that describes that a command was issued. But then again, every message can be seen as fact/event, so we would end up with using "event" as general-purpose term.

The main issue is that there is already a widespread & established language/terminology, where "message" is the general term. And there are three different types of messages: Commands, Queries and Events.

These message types do not imply whether they are distributed and processed "synchronously" or asynchronously (via a broker). However, events are typically assumed to be distributed asynchronously, while commands & queries are not.

And there is even a term many people use for what you describe as "Command Event": an asynchronous Command. Here, "asynchronous" implies the absence of a possibility to send a direct response. In this case, an event can be used as response (with a correlation identifier / return address).

I do think this pattern could be clearer and in this regard though as I totally get the confusion here, but the common connotation of command, stemming back to Bertrand Meyer’s CQS (Command Query Separation) principle, causes confusion.

Unless I completely misunderstood CQS, I don't understand what you mean with that. Even Wikipedia is pretty clear on that. Only queries have a return value. Commands must not.

The part "Considerations" in the page reads to me like you are describing a long-running process, more specifically a choreography (again an established term). There are different ways to model & implement such a process and most of the times they involve a combination of Commands & Events.

With all that said, it's up to you what terms you use. However, to the best of my knowledge, there is a quite large community that uses an established terminology that conflicts with it. And even more, there is already a name for the pattern you are describing (either simply command or async command).

I think due to the reach Confluent's documentation/posts have, it would be beneficial for the community to spread the knowledge of well-established terminology instead of causing confusion.

[alexlawrence]

And then have a bigger one that is really based on events as intended and in use in today's EDA based sytems.

I've heard people using Message-Driven Architecture (or Messaging Architecture) as a replacement for EDA to account for other messages such as Commands and Queries.

[alexeyzimarev]

[Events](../event/event.md) often fall into one of two categories: messages and commands.

This statement sounds weird to me, as both events and commands are, essentially, messages. Saying that event can be a message or a command is essentially saying that command is not a message, but it's an event. It makes my brain explode.

I believe, we agreed that events convey facts that happened, but commands convey intent and can be rejected. That's how events and commands are semantically different, but both are messages.