Differences between Event-driven and Command line programming

The aim is represented by the command. It is directed towards a certain market. When you ask
for "hand me the salt," it can become your ally. It might be a service request from an application
with the aim of "adding a user" or "changing the order status to confirmed." In order to ensure
that the request is carried out, the command's sender must be aware of the receiver. Naturally, the
recipient has the option to decline by either failing to provide the salt or raising an objection
when the request is being processed.

The event itself then stands in for a historical truth. It conveys details about a task completed.
Nothing can be undone once it has been seen. The phrases "user added" and "order status
changed to confirmed" are instances of historical facts. Events are broadcast rather than directed
to a specific audience. It resembles sharing a story at a gathering. We hope that someone will pay
attention to what we have to say, but we can find out very quickly that nobody is.

Figure 1

https://dev.to/milhamh95/difference-between-message-vs-event-vs-command-
17h0
The intention of commands is to elicit behavior. You send a command to your system when you
want something to happen. Your service offers a certain sort of capacity, and you must find a
means to expose it. That is accomplished through a command. A command has two components.
The first is the message itself (the command), which is the order and purpose for causing the
activity. The second is a consumer or handler for the command, carrying out and carrying out the
desired activity. Each command has a single consumer/handler that is located inside the same
logical boundary as the command's specification and schema. Many distinct logical boundaries
can send commands. Senders can come in a wide variety.

Events are used to inform other system components about an event that took place inside a
service boundary. Something took place. Typically, the execution of a command might result in
an event. Events consist of two sections. The first is the message itself, also known as the event,
which serves as a notification that something happened. The second is the event's consumer or
handler, which will respond and act in response to its occurrence. There is just one logical
boundary that publishes an event and owns the schema. Consumers of events can exist under a
wide range of logical constraints. A consumer for an event could not exist at all. Consequently,
there might be one consumer or several.

To summarize commands and events we can compare their purpose, ownership, consumers,
senders, and naming.
Let's examine a straightforward sequential application that increases numbers. We understand
that this sort of program would need us to identify at least three variables based on previously
acquired concepts and preceding chapters. Two variables would contain the numbers that would
be combined to make the total, and one variable would keep the total. Our application may ask
us to add the two values, and it would then automatically display the result on the screen.

We get several advantages from event-driven architecture that we don't get from sequential
execution. In the first illustration, the programmer oversaw program execution and chose when
to prompt the user for input, do the computation, and shut down the application. The event-
driven approach provides the user control and enables them to repeatedly execute the software.
When the software is finished and must be terminated, the user decides.