Commands are phrases in the imperative present tense, like a git commit. Like a git commit they can carry with them some data, potentially used to alter state.

I have been using pascal case to define my commands:
"VisitorSubmitContactForm", "UserUpdateEmail", "ManagerOverridePrice"
[Actor][Action][Subject], Who's doing what to what

Commands can be accepted or rejected, just like in real life.
Your business logic validation, authentication, et cetera lives right here. Commands are the way your system receives state altering data, you decide what to accept or reject right here.

Taken directly from the Event Sourcing world. A Stream is a named series of Events. Simple, but extremely powerful concept.

Required viewing:

If a command is accepted, one or more Events can be persisted [to a stream]. The command examples above could generate the following Events:
"VisitorSubmittedContactForm", "UserUpdatedEmail", "ManagerOverrodePrice"
Aside from the event name, the data from the command is stored alongside, or not. Additional data can be added or anything omitted, there's no hard rule, do whatever is needed for your domain.

Let's get philosophical for a moment (Just kidding, I always am). These events are named in past tense, because they are reflected upon (used to alter state) at a future time, even if that future time is the next cpu tick. Likewise, when something happens (an event) in physical reality, we only observe it happening after it has already happened, and our response to it can only happen after the observation. Consider the chain of causality: prime mover causes an event (user clicks a button), we observe it (pub/sub), we consider what we observed (possible conditional logic), and possibly take action (effect) to become our own prime mover. This chain of causation can continue indefinitely, or until there's no more energy left in existence with which to convert into expressions of will.
Also, consider Pharaoh Rameses II's proclamation from "The Ten Commandments" (1956) (so aptly named?) - "So let it be written, so let it be done". What is written? The Event. What is done? The Effect(s).

Ah, the effects. Those that do as they are told. Unwilling links in the chain [of cause and effect].
Something has been written, and now something will be done.
Here's some common examples:
A form submission event (VisitorSubmittedContactForm) lands in the event store and in response to that we'll drop a document in mongo.
Of course more than one effect can be bound, so in addition we'll create a Task in our system for a sales agent to munch on.
A note on TIME. Effects are real-time only. There's no such thing as "replaying" effects. Merv respects nature and in nature events happen only in the now, and their effects also only happen in the now. Note that I'm not talking about the concept of replaying Events in order to build or rebuild state; that is done constantly in Merv. Events get played and replayed frequently, like your VHS copy of Beauty and the Beast as a child (you can an admit it, err, ok I will), but Effects are for the now only.
Since Effects are time-safe, you can know that you're safe to do stuff that is time relevant, like send a text message or webhook.

Some event sourcers call these aggregates. I use a more accurate word. Derivative.
The Latin roots of “derive” are de, a prefix that means “from” and rivus, a word that means “stream”.
The etymology lines up perfectly here. A derivative in Merv is the current state of a stream.

You can think of each stream ("Order:123") to be like a git repo. After you play all Events ("commits") forward you end with the "current state" of the Order. Say you want to render a list of Orders on your CRM.. You can't simply play all the many events forward with every request in order to yield the current state of each order. The read store is a separate database that stores the current state of each stream that you're interested in querying. I've been liking mongo recently.
Your GraphQL resolvers will only know about the read store and not the streams. Not a hard rule, but for most cases this will be true. (Obviously a single stream could supply data to a singular resolver endpoint, just not a "list of Orders")