2

In the context of domain-driven design, events usually describe something that has already happened (domain events, integration events). Commands on the other hand are directives that may or may not be executed in the future. This distinction is also given in another SO answer.

However, in event sourcing, we have events that describe the delta of a change - these events exist even before objects apply() them, and are persisted in an event store. In a sense, they have characteristics of both a domain/integration event and a command.

How am I supposed to name and distinguish these kinds of events from real domain events? How do commands translate into "event-sourcing" events?

Double M
  • 446
  • 3
  • 8
  • 1
    Possible duplicate of [When using DDD and CRQS, should be exactly one event per command?](https://softwareengineering.stackexchange.com/questions/305529/when-using-ddd-and-crqs-should-be-exactly-one-event-per-command) – Doc Brown Oct 22 '18 at 00:32
  • @DocBrown The linked answer is good, but does not provide as much clarification on Domain Events vs. Event Sourcing Events as the answer provided below. – Double M Oct 22 '18 at 16:23

1 Answers1

3

Warning: the literature isn't particularly good, for a number of reasons. It's not your fault.

At its core, event sourcing is about representing the current state of a model as a history of changes with domain semantics. The only difference between these changes, and what Martin Fowler referred to as Domain Events, is that they are not inputs to the model, but rather outputs from the model.

They are descriptions of changes that the domain model made to its own state, described as messages with domain semantics.

The only real distinction to be made is the authority for the event; for input domain events, the authority is out there in the real world somewhere. CashWithdrawn; Bob really did get money out of the ATM. CashDeposited; Bob really did put money into the ATM. When the domain model is the authority, you get something like OverdraftLimitExceeded -- we've reviewed all of Bob's ATM transactions, and he owes us money. It's still an event - it describes the result of a computation that the domain model made in the past.

How am I supposed to name and distinguish these kinds of events from real domain events?

Honestly? You aren't supposed to distinguish them; they are still representations of things that happened in the past, so they should have domain semantics with the appropriate "past" verb tenses.

It may help to keep in mind that, when we later input these events into a subscriber, they are indistinguishable from "domain events".

VoiceOfUnreason
  • 32,131
  • 2
  • 42
  • 79