An architectural style in which a system’s components communicate with one another asynchronously by exchanging event messages.

Useful in designing loosely coupled, scalable, fault-tolerant distributed systems.

Careless application of EDA can turn a modular monolith into a distributed big ball of mud.

Types of messages

Events

A message describing a change that has already happened in the system. Formulated in past tense (DeliveryConfirmed).

Recipient cannot reject an event, but can issue a compensating action to revert an event.

Events in EDA-based systems are first-class design elements that affect the boundaries of the component and how components are integrated.

Types of events

Link to original

Commands

A message describing an operation that has to be executed.

Command can be rejected by the command’s target if they are invalid or if it contradicts the system’s business rules.

Design heuristics

Assume the worst

  • The network is going to be slow.
  • Servers will fail.
  • Events will arrive out of order.
  • Events will be duplicated.
  • Events will occur most frequently on weekends and public holidays.

Avoid the “things will be okay” mindset.

Use public and private events

Be wary of exposing implementation details when publishing domain events.

Treat events as a part of the bounded context’s public interface.

Leverage the different types of events to minimize the public interface when needed.

Instead of using domain events for communication with external bounded contexts, consider designing a set of dedicated public domain events.

Evaluate consistency requirements

If the components can settle for eventually consistent data, use event-carried state transfer messages.

If the consumer needs the latest producer’s state, issue an event notification to force consumer to fetch up-to-date state in a subsequent query.

See also