While I like the fact that the author is attempting to explicitly delineate commands vs events, IMO the attempt misses the mark in a few ways. A command is not

While I like the fact that the author is attempting to explicitly delineate commands vs events, IMO the attempt misses the mark in a few ways. A command is not required to change state (especially as demonstrated by use of HTTP POST/PUT/DELETE)... "show me X" is a command that requires action on the part of the server and it's perfectly correct to issue the event "showed X to user" upon success. It's the reason we have log files and metrics datastores. I'd argue that more correct is to view the overall system as stimulus and response. A request, of any type, by the client is a stimulus to the server and it will attempt to respond. The combination of the stimulus and response (either successful or not) results in the consequences of the combined stimulus/response... including an event. In the case of the author's example regarding the human opening the door the other necessary tasks such as "breathe" and "pump blood" are assumed to occur because they are important and necessary but are only consequential to the event if they are absent. In the same way writing to data stores, rendering UI, etc are the equivalent of "breathing and pumping blood"... they are events only if they fail which produces an error event. Events are higher-level concepts defined by the business logic or the programmer as important to the system. "New user created" is an abstract by-product of a stimulus/response that is meaningful to the business or programmer... "wrote to database" generally is not unless needed for debugging. "Failed to write to database" certainly has more meaning which is why error events are more granular.