When building event-driven architectures, how do we make sure they are successful today, tomorrow and in a few years’ time?

I have distilled what I believe a successful event-driven architecture into three main areas, first is identify events and the importance in understanding he behaviour of a system. Followed by understanding messaging and integration patterns then finally spending time to understanding operational and maintenance going into the future.

Identify and design

• When you start building event-driven architectures you have two options, start to implement or stop and understand the behaviour of your system and identify your events.

• Spending time understanding your system, finding events, commands, systems and aggregates can really help you model a successful event-driven architecture.

• Event storming is a great workshop to run with your domain experts to identify events, commands and aggregates.

• Event storming brings domain experts together to discuss and negotiate how the system works and the naming of your domains (aggregates) and events. It’s important to have event names that are explicit and clear.

• Once you have shared understanding of your system and identified your events, it can paint the picture you can use to start modelling your architecture and events.

• Remember event storming is not just a workshop you run at the start, come back to it in the future, keep using it to help retain the shared understanding.

Collection of patterns

• Event-driven architecture is just a collection of patterns, you may have messaging patterns and also integration patterns inside your architecture depending on what you need.

• Messaging patterns include patterns like point-to-point messaging, publish/subscribe, and event streaming. You can use these methods to pass messages/events around your architecture, and over time your architecture will likely have many of these messaging patterns.

• Integration patterns are slightly different, these are patterns you can use to help you overcome certain situations when dealing with event-driven architectures or messaging patterns. Examples of these would be claim check pattern, splitter pattern, or message translator pattern all can be found in enterprise integration patterns book.

• Understanding messaging and integration patterns can help you build successful event-driven architectures.

Operational and maintenance

• It’s important to consider what your event-driven architecture will look like in 6, 12 or even 24 months. How will people find events? How will you change events? Who is producing what?

• Documenting your event-driven architecture can really help you keep maintenance under control when building your architecture. Start to think about documenting who is consuming/producing what.

• Having standards in your events can also help you scale your event-driven architecture. What information should be all events in your architecture? Maybe create a custom SDK to help you build these within your org?

• Try and think about problems you may have in the future, and spend time upfront thinking about practices you can introduce to help you mitigate away from these issues.

Extra Resources

• Event storming can help! - Event storming is a great workshop to help you identify and understand the behavior of your system. Run these workshops to help identify events, commands, systems and aggregates. Perfect way to get shared understanding and get started with event-driven architecture.
• Domain driven design and EDA - We can take so many tips from the domain driven design community when building event-driven architectures. Here is a visual to dive deeper.
• What is point-to-point messaging - Understanding messaging can help, here is a visual to help you understand what point-to-point messaging is.
• What do we mean by publish/subscribe - Notify downstream consumers that something has happened. When you build event-driven architectures no doubt you may need this pattern. This visual dives deeper.
• Discover your events - In the future people will want to know what events you have, and how you can discover them. This visual dives into event-driven architecture documentation options with some open-source projects that can help.