Domain Event

A domain event records something meaningful that happened in the domain, as a named past-tense fact. Handlers react to it within the same context, and it can also be published across a Bounded Context boundary so another context learns what occurred without the two sharing a model.

The honest attribution: this is the pattern the community most treats as core tactical DDD, and it is barely in Evans’s 2003 book. Fowler’s 2005 write-up of domain events does not mention DDD; Dahan’s 2009 case for them does not cite Evans. Domain events are the field’s most successful addition to tactical DDD, built on a seam Evans left open, not one of his original building blocks.

They are also not a bundle with event sourcing or CQRS. A domain event is a fact you publish; the other two are a persistence strategy and a read/write split. The three have a one-way dependency and are best kept separate in your head.

Signal: events are named as facts in the past tense (“order placed”, not “place order”), and a subscribing context reacts without reaching into the publisher’s model. Part of Domain-Driven Design.

Sources

• Martin Fowler, Domain Event (2005): the write-up that never mentions DDD.
• Udi Dahan, Domain Events – Salvation (2009): the case for explicit domain events, also without citing Evans.