Event-driven architectures have been around for decades but are becoming more accessible to us. As we all explore building these types of architectures there is often one thing that is overlooked which is governance.

How should you govern your event architecture? What tips are there? Where should you start? This visual can help.

Big ball of mud

• A term taken from domain driven design, but in essence this is what can happen easily without some form of governance in your EDA.

• EDA provides the ability to add producers/consumers over time, and this landscape can grow which is great… but without keeping some kind overview or knowledge of who is consuming what can be hard to manage versions, make changes, and visualise / document architectures.

• It’s important to consider governance when building EDA, thinking about your event standards, discoverability, documentation and levels of coupling. Without thinking about this can lead to big balls of mud, which can easily be avoiding with levels of governance and design.

Discoverability

• Discoverability is still a known issue when building event-driven architectures. Understanding who is producing/consuming what can help you paint the picture of your EDA landscape.

• When you have new teams or people joining teams, they may want to consume events, but how can they find the events? What does the event structure look like? What do the properties mean on the event? All these things come down to documentation/governance.

• When you are building your EDA think about discoverability. Discoverability requirements will vary depending on the type of event you are producing. For example, is this event intended to be private within your boundary? Public across boundaries? Or maybe even external to other companies? The level of discoverability will change depending on this.

Define responsibilities

• As your building EDA in your organisation think about the responsibilities of your teams? Do you have stream-aligned teams? What are your producers’ responsibilities or your consumers?

• Some responsibilities you may want to consider; do we validate our events before publishing? Do we want to validate our events when consuming? Are the producers responsible for the schema of the event? Where is this documented? Who is responsible for version control? What is your version control strategy? Should we all adhere to common fields and define them (example, order_status, orderStatus, status) in the order events, or other domain events, do we need a catalog of terms?

• Having clear responsibilities can help you scale your EDA over time. Think about what you expect from your producers and consumers and your teams. Set standards and stick to them.

• Maybe be worth exploring having cross functional teams that champion and manage your EDA governance strategy.

Explore standards and specifications

• There are awesome open-source projects and people out there working on solving complex problems and defining standards to help us.

• If you want to publish events using standards you may want to look at CloudEvents. A specification that is designed to help you define your messages, that can be used regardless of your programming language, broker and protocols.

• If you want to document your event-driven architecture you may want to explore AsyncAPI. This has a fantastic community behind it, and a range of open-source projects to help you define who is producing/consuming what, with a range of protocol support.

• If you want to document services, domains, events then EventCatalog may help (shameless plug), I built this tool to help you all document your EDA, the community is growing and may be worth checking out if you struggle with any documentation solutions.

Extra Resources

• Empowering Architectural Evolution: Governing Event-Driven Solutions (Video) - Great video here by Sam Dengler about governance and EDA. This is a must watch video if you want to learn more. Sam is a very smart person with some awesome insights here.

• API Federation - Great blog post here by Daniel Kocot I enjoyed reading. Talks about API federation and many of these topics he talks about can be linked back to EDA governance.

• CloudEvents - Have a look at this specification and this community. They are doing great things here around events and also discoverability. Worth exploring!

• AsyncAPI - Great standard to help you document your EDA. Worth exploring this and understanding how it can help you. They have a great community if you want to join them and help out!

• Dive deeper into operational and maintenance (Video) - In this video I talk about governance in more detail, this may help you learn more and dive deeper into the subject.

• List of EDA talks - A list of talks I have given over the past couple of years, to help you dive into EDA. I talk about governance, standards, design and much more. Hopefully these can help.