When designing your events, I believe it’s important to have explicit events for your event-driven-architectures. Define your events, define schemas and make sure the event itself is clear and intent can be understood. Also note producers that do not provide contracts (schemas) have increased chance of producing implicit events for downstream consumers.

Explicit Events

• Be clear on the event and it’s intent
• Use clear naming conventions
• Use schemas to help define contracts
• Gives stability to both producers and consumers

Implicit Events

• Unclear event intent, try to avoid
• Unclear naming conventions
• Assumptions can be made
• Breaking changes possible without contract/schema.

Extra Resources

• EventStorming - EventStorming can help you identify your events in your system, using other stake holders it can be a natural way of defining explicit events, as events naming is often discussed.
• EDA Documentation - Documentation can help have explicit events. If consumers can discover and understand your events you are half way there.
• Event First Thinking - Events are important, designing them, thinking about them, taking your time. Treat events as first-class citizens with Event First Thinking.
• Event Types - Understand event types can help you along your event design path.
• Commands vs Events - Two different things. Be clear if your message is a command or event.
• Building Event-Driven Microservices - Thoughts generated from notes from this book.