Skip to main content

Event Modeling Lab

Retrieval Prompts​

  1. State the three non-negotiable properties of an event.
  2. Give a one-sentence test for "is this an event or a command?"
  3. Name the three minimum fields every event payload must carry and why.
  4. Explain why a "correction" to an event is a new event, not a mutation.
  5. Describe the shift from CRUD to events in one sentence.

Compare and Distinguish​

Separate these pairs clearly:

  • event vs command (intent, tense, consumer count, reply expectation)
  • event vs query (does anyone reply? does the caller wait?)
  • CRUD update vs domain event (UPDATE email = ? vs EmailAddressChanged)
  • audit log vs event stream (read-only for humans vs consumed by systems)
  • event notification vs event-carried state transfer (thin vs fat payload, preview of Cluster 2)

Common Mistake Check​

For each statement, name the error and give the corrected form:

  1. "We publish SendWelcomeEmail to Kafka because it is an event-driven system."
  2. "Our event is OrderUpdated with a payload of the new order state."
  3. "We republish the same event with a correction when we find a bug in the payload."
  4. "Every database UPDATE in our service becomes a domain event."
  5. "Our event payload is just {'order_id': '...'} because the consumer can query back for details."
  6. "We name our event topic orders and put creates, updates, deletes, and queries on it."

Mini Application -- Event Storming a Bounded Context​

Pick a bounded context you know (checkout, ride dispatch, support tickets, insurance claims). In 40 minutes:

Step 1 (10 min): Raw brain dump​

  • list every domain transition (state change that matters to someone) in past tense
  • aim for 15-25 candidate events
  • do not edit yet; it is a brainstorm

Step 2 (10 min): Rename and prune​

For each candidate:

  • rewrite in clean past tense (OrderPlaced, not Order Was Placed by a User)
  • delete any that are commands in disguise
  • mark those that are really one event split into two, or two events collapsed into one
  • end with 10-15 clean events

Step 3 (10 min): Draft payload and metadata​

For 5 of the events, write:

  • event_id, occurred_at, subject_id
  • 3-6 payload fields
  • which service is the producer
  • two plausible consumers

Step 4 (10 min): The disguised-command test​

For each of the 5 events, apply the checklist from Concept 01:

  1. past tense?
  2. fact, not instruction?
  3. ≥2 plausible consumers?
  4. producer is authoritative?
  5. payload is meaningful without a callback (or deliberately notification-style)?
  6. has event_id and occurred_at?

Mark any that fail. Rewrite or discard.

The Disguised Command Drill​

Each of the following is disguised as an event. Rewrite each as the fact it should express. Hint: the form is usually X -> XWas[Verb]ed or XHappened.

  1. SendPasswordResetEmail ->
  2. RetryFailedPayment ->
  3. NotifyDriverOfNewTrip ->
  4. RefundCustomer ->
  5. AllocateWarehouseSlot ->
  6. RollbackOrderOnError ->

Sample expected answers: PasswordResetRequested, PaymentFailed, TripAssigned, RefundIssued, WarehouseSlotAllocated, OrderAborted. Your answers do not have to match exactly -- they just have to be facts, not instructions.

Common Confusions to Surface​

After you finish, write one short sentence on each that you now understand better:

  • why past-tense naming is not cosmetic
  • why two consumers minimum is a useful "is it really an event?" check
  • why the event producer must be the authoritative source
  • why emitting one fat event carrying three different transitions is a modeling bug

Evidence Check​

This page is complete only when:

  • You produced an event catalog of 10-15 events with payloads for a real bounded context.
  • You correctly relabeled all 6 disguised commands as facts.
  • You can articulate, without the checklist, why a given message is an event or a command.
  • You identified at least one place in your own or a known system where a command is disguised as an event.