
The Power of Commands and Events - fagnerbrack
https://medium.com/@fagnerbrack/the-power-of-commands-and-events-ec6d2b3f856d
======
mason55
Martin Fowler has some good info about this as well.

[https://martinfowler.com/articles/201701-event-
driven.html](https://martinfowler.com/articles/201701-event-driven.html)

What usually gets skipped is the added complexity and emergent behavior that
can arise from event driven systems. If you change you application to operate
this way then you're introducing a lot of the problems that you get with
distributed apps (difficult to do transactionality, no guaranteed delivery of
messages, etc) even if the whole thing runs locally.

------
fallous
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.

~~~
fagnerbrack
Commands that return data are called queries. You shouldn't change the state
when running a query, so there's no reason to call them commands.

~~~
fallous
I've already stated that a query shouldn't necessarily result in a change of
state, but a command to return data is still a command and there's every
reason to call them that because they result in work performed.

~~~
fagnerbrack
I guess at this point we're just arguing about etymology. The important bit is
to differentiate between read/command/queries and write/commands, whatever
those names may be.

Anyway, I just didn't touch queries in this post cause it would make it longer
than 5 minutes. I have a follow-up draft.

------
ryanmarsh
I’m working on a POC for Serverless event sourcing using graphql as the
boundary (mutations are commands, queries are reads).

I recently read about event sourcing vs command sourcing and the perils of the
latter.

Be careful my friends.

I think Redux serves as a great model for thinking about event sourcing.

State (the read model) is a pure function of the action history (event log).
Side effects happen in action creators (commands) before they are committed to
the store (log).

