In lesson 4.3.2 you decided that the sales opportunity doesn't belong in the quote: when a quote is accepted, sales is supposed to react, but in a transaction of its own. That takes a way for an aggregate to say “this happened” without knowing who is listening. That way is called a domain event.
In this lesson the quote records two events, QuoteSent and QuoteAccepted. The quotes publish them as a contract,
and sales then plans a call to the customer. In the end, sales knows the quotes' contract, but the quotes
know nothing about sales.
What a domain event is
A domain event is a fact from the business that has already happened. You know such events from the event storming in lesson 4.2.2: the orange sticky notes on the timeline. “Quote sent”, “quote accepted”, “appointment booked”. Three rules for their names follow from that:
- Past tense.
QuoteSent, notSendQuote. An event is not an order to do something, but the report that it has been done. Nobody can object to it, it has already happened. - Words from the glossary. If the glossary says “quote =
Quote” and “send =Send”, the event is calledQuoteSent. An event namedQuoteStatusChangedsays nothing about what happened, and forces every receiver to look up the old and the new status. - One event per business operation. If the domain expert describes “accepted” and “rejected” as two different things, they are two events, even if both change the status.
An event is something different from a command. A command (“send the quote”) can fail, and the aggregate decides that. An event comes into being only when the aggregate has said yes. That's why only the aggregate itself creates its events, in the same method that checks the command.