Matching types of events to the tasks at hand makes the resultant design orders of magnitude less coupled, more flexible, and fault tolerant. Let’s formulate the design heuristics behind the applied changes.

Assume the worst

As Andrew Grove put it, only the paranoid survive.3 Use this as a guiding principle when designing event-driven systems:

• The network is going to be slow.

• Servers will fail at the most inconvenient moment.

• Events will arrive out of order.

• Events will be duplicated.

Most importantly, these events will occur most frequently on weekends and public holidays.

The word driven in event-driven architecture means your whole system depends on successful delivery of the messages. Hence, avoid the “things will be okay” mindset like the plague. Ensure that the events are always delivered consistently, no matter what:

• Use the outbox pattern to publish messages reliably.

• When publishing messages, ensure that the subscribers will be able to dedupli‐ cate the messages and identify and reorder out-of-order messages.

• Leverage the saga and process manager patterns when orchestrating cross- bounded context processes that require issuing compensating actions.

Use public and private events

Be wary of exposing implementation details when publishing domain events, espe‐ cially in event-sourced aggregates. Treat events as an inherent part of the bounded context’s public interface. Therefore, when implementing the open-host service pat‐ tern, ensure that the events are reflected in the bounded context’s published language. Patterns for transforming event-based models are discussed in Chapter 9.

When designing bounded contexts’ public interfaces, leverage the different types of events. Event-carried state transfer messages compress the implementation model

3 Grove, A. S. (1998). Only the Paranoid Survive. London: HarperCollins Business.

into a more compact model that communicates only the information the consumers need.

Event notification messages can be used to further minimize the public interface.

Finally, sparingly use domain events for communication with external bounded con‐ texts. Consider designing a set of dedicated public domain events.

Evaluate consistency requirements

When designing event-driven communication, evaluate the bounded contexts’ con‐ sistency requirements as an additional heuristic for choosing the event type:

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

• If the consumer needs to read the last write in the producer’s state, issue an event notification message, with a subsequent query to fetch the producer’s up-to-date state.