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
Get Seyon Suriyakumaran’s stories in your inbox
Join Medium for free to get updates from this writer.
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.
