The big picture from lesson 4.2.2 shows what happens in the office. It doesn't show why it happens: who decides, what they need to see in order to do so, and which rule ties one event to the next. You catch up on that now, for one section: phases 4 to 6, from the draft of a quote to its acceptance. At the end you know which rules need a person, which may run by themselves and where the first aggregates lie, which you build in module 4.3.
The grammar of a process
In detail, event storming has a fixed grammar. A process always reads in this order:
Person ── sees ──► Read model
│
└── gives ──► Command ──► Aggregate ──► Event ──► Policy ──► Command ──► …
│
└──► Read model (for the next person)
External system or clock ──► Event
Four colors join the four from the big picture:
| Color | Meaning | Example |
|---|---|---|
| blue | Command: an intention to do something, in the imperative | Send quote |
| purple | Policy: “whenever … then …” | Whenever a quote has been sent, it is attached to the sales opportunity. |
| green | Read model: what a person sees in order to decide | Quotes for approval |
| yellow, large | Aggregate: the thing that checks a command and accepts or rejects it | Quote |
A command can fail; an event has happened. That's why the aggregate sits between the two: it checks the command against its rules. If everything is in order, the event comes into being. If not, none does, and the person gets an error message.
In the big picture the events stood in plain language. From now on, every command and every event also gets the name it will carry in the code:
the word from the glossary and the verb after it. “Send quote” becomes SendQuote, “Quote sent” becomes QuoteSent. Both stand on the
sticky note: the plain wording large, the code name small underneath.