API Evangelist Conversation with David Boyne on Event-Driven Discoverability, Domain-Driven Catalogs, and Building a Sustainable Open Core

Event Catalog is a documentation tool to bring discoverability to architecture. Most people building distributed systems end up in chaos because no one is documenting anything. We have OpenAPI and AsyncAPI and things like that, but there is still a lot of mess. Event Catalog really just helps people save time and puts some controls around the chaos. Three years ago the project started off as a side project for cataloging events — that was it. Since then it has grown into a lot of domain-driven design — domains, sub-domains, bounded context, all those kinds of things. When you take the primitives away from all of this it’s just like Lego blocks, so now I just say discoverability for architecture, because most people are building REST, stream-based, and message-based architectures at the same time. Why not just bring discoverability to it all?

The main focus is still event-driven architectures, because a lot of people in that area are just struggling with chaos, especially at scale. At day one, having five or ten events is fine — three services, all good. By day one hundred, when you have a thousand events and fifty services, it is just chaos and everyone is asking “what the hell’s going on?” Everyone I speak to is literally saying “we’re in a mess and we need help.” People don’t know what they don’t know, and they don’t know how to find this information. Especially in enterprises, the information is there — it’s just a question of whether we can make it visible. I’m a very visual person, so if we can make this visible through visualizations and graphics, it helps tell a story. I always thought it was a developer’s problem to solve, but the more I’m in this space, it’s not — it’s a product and a business problem. There are very different personas coming to Event Catalog for very different levels of complexity.

I was on the AsyncAPI team for a while with Fran and those guys, so this stuff is a huge part of my heart. Event Catalog is focused on primitives — messages, queries, commands, events, services, not really technology. When you look at specifications like OpenAPI, GraphQL, and AsyncAPI, the primitives are the same: a message, a query, a REST endpoint, request/response, here’s some data. All Event Catalog really does is translate these things into those primitives, and once they’re primitives, you can document them. The reason to integrate with them is because they are standards. OpenAPI has been around for many, many years; AsyncAPI is still earlier in its adoption curve, like OpenAPI was. But why not support these specifications? Most people are using them anyway — just ingest them and help people document them and use them as a foundation.

Studio took a lot of inspiration from event storming, modeling, and the DDD side of things. I always found it a bit weird that you would model something on post-it notes and then have no artifact at the end of it. The original thought was: what if we could model something and end up with an Event Catalog as a baseline — some documentation, something we can build on? Once you document your architecture and add the meaning, the question becomes “why can’t I use my architecture primitives — my REST endpoints, my messages, my schemas — to actually design things, document workflows, or describe business processes?” Why does everything have to be so independent of each other? Why do I have to go to a Miro board and use post-it notes when I already have the essence of the architecture somewhere? Studio is about taking documentation and using it to drive design — and bringing collaboration and feedback back into the design loop.

I think so — many people are using it for different types of things really. Some are mapping whole domains and then getting granular at a lower level, which overlaps with the C4 model and its different levels of information. Where I think Event Catalog naturally goes is domains, services, the messages inside the services, the schemas. Product owners don’t care about schemas, but they care about the domains, the opportunity, what we have, what we’re missing — that kind of stuff. It’s an interesting space, and to be honest I try to speak to the users of Event Catalog and the open source community and let them steer the ship. I just kind of try to steer it in the right direction. These people are using it day-to-day, so they know.

It has been a journey. At the start I had no business model — I just wanted to do this thing, and obviously that doesn’t pay the bills. I found a few sponsors at the start, which was really cool, but the question becomes: how do you make money off open source software? What I landed on was an open core model. I understand my audience pretty well because I’ve been in it for the last ten to twenty years, so it’s really about picking what features people will pay for, and at what scale. It’s a hard problem — many people have struggled in this area. I’m not sure I’ve got it right, but I have paying customers and it’s sustainable, which is really cool. Event Catalog is also all self-hosted. A lot of people ask why it isn’t a SaaS, and the honest answer is I don’t want to be responsible for data, compliance, SLAs — especially as a single maintainer. License keys and license models work well, because most enterprises don’t want to mess around with workarounds or forks. They will just pay a license fee to get a clean package.

I stumbled across DDD a few years ago when I was deep in event-driven architecture, and there’s just this huge synergy. Everything starts to make a lot of sense, especially using events to communicate across boundaries. When you bring elements of DDD and the technical community of EDA together — without focusing on the implementation details — there is a lot to explore and a lot of value to be captured. Most documentation tools focus on API documentation: take an OpenAPI file and do some cool stuff. That’s fine. But the questions I always have are about business context — why does this thing exist, why does this model exist, who owns this, what is the business process, how do you get from A to Z? Those questions can’t be captured in an OpenAPI file alone. The idea is to take what we have, add meaning on top, and then from a business point of view we can finally answer those questions — not just the technical ones.

I think so. With AI in enterprise conversations you either get people who are not interested at all or people who are super into it — that contrast fascinated me. The way I see it: if you’ve documented your boundaries, your ubiquitous language, your services and how they connect, and you’ve visualized them, you have a core foundation. You can use that as a foundation for context for other things. I’ve experimented with asking, “I want to build this new feature — what APIs, what events, what messages do we have, who owns them, and what are the schemas?” and it does a very good job of finding that information. Even away from chat, imagine taking a picture of an event storming model, dropping it into Event Catalog, and letting it auto-document based on that. I think the core foundational view of the organization — from a domain point of view, language, modeling, “what is your core domain, what is supporting, what is generic” — is what AI should consume as context.

I’ve worked with enterprises that brought me in as part of Center of Excellence engagements — very top-down, CIO and CTO-led, week-long domain-driven design sessions. Productive, needed, but many fell flat on their face. I’m a big fan of measuring the existing outputs of a large system to understand what it actually is, rather than trying to master plan the enterprise — things move too fast for that. That’s why I find Event Catalog’s approach unique: using events to make discovery and visibility happen in motion, then giving us the tools to start making sense of that in real time. People don’t know what they don’t know, and they don’t know how to find this information. The information is there — it just needs to be made visible.

Different companies are using Event Catalog in different ways. Some champions are technical-facing; some are more business-facing. What I’m learning is there are different personas using it. Something I’m exploring right now is whether Event Catalog should have a different view per persona — can I look at a domain in a different way depending on how I’m coming at it? A product owner might not be interested in your Avro schema, but they’re very interested in other details. Event Catalog started off as this technical thing to document some events, but because we layered DDD and the business domain on top, it’s turning out to be really valuable for a lot of different team members.

Biggest need is more time and more hands. From an open source perspective, what I most need is feedback. If you’re using it, just feedback — and keep feeding back. If it’s not good enough, if it isn’t working a particular way, come on Discord and share that. A lot of us consume open source and never feed back; you only get the core people that do. So if you’re using it, come share. That’s all I really ask, so we can make it better. And if you want to contribute, I try to mark good first issues on GitHub — pick some up. Use cases, stories, and detailed studies of how it’s being used are incredibly valuable. That’s what helps an open source project grow.