Skip to content

Producing Events

When a command has been validated and processed, the outcome is one or more events.

These events represent facts – something that has already happened in the domain.

They are the result of applying business logic to the current state. And once produced, they become part of the system's history.

In Our Library

Imagine the command handler accepted a BorrowBook command.

If all checks passed, it would produce an event like:

BookBorrowed {
  memberId: "m-1234"
  copyId: "c-9876"
  borrowedAt: "2025-06-09T10:34:00Z"
  dueDate: "2025-06-30T23:59:59Z"
}

This event is not a suggestion or a plan – it's a statement of fact: the book has been borrowed.

Events Are Immutable

Once created, events are never changed or deleted. They capture exactly what happened – even if the outcome was unexpected or invalid in hindsight.

That makes them perfect for:

  • Auditing ("When was this borrowed?")
  • Debugging ("Why did this happen?")
  • Understanding ("How did we get here?")

Event Streams

Events are typically grouped into streams.

Each stream contains all events related to a specific entity – for example, one per book copy or per loan.

Over time, the stream grows – and becomes the full behavioral history of that entity.

What Happens Next?

Once produced, events are:

  1. Stored permanently in the event store
  2. Published to the rest of the system so other components can react

Next up: Storing Events – learn how and where events are stored.