Why EventCatalog?
Many companies adopting event-driven architectures end up in a distributed big ball of mud.
There can be many reasons for this, but one of the main reasons is that teams are not documenting their architectures, they lack governance and discoverability.
Many questions emerge over time, such as:
- What messages do we have?
- How are consumers and producers using these messages?
- What's the business context behind this architecture?
- Where can I find the schemas of these messages?
- What services or domains do we have in our architecture?
- How can I make changes?
- Who is consuming these messages?
- And the list goes on...
EventCatalog was designed to help avoid the chaos, by providing a way to document your architecture, visualize it, and provide tools to help you answer questions about it.
EventCatalog is a open source project to help you bring discoverability to your architecture through documentation, visualization and design.
What can EventCatalog do for you?β
- Save time, by helping your developers, architects and business stakeholders quickly understand and find the information they need.
- Bring clarity to your architecture, by visualizing it in a way that is easy to understand.
- Document your domains, services, messages (events, commands, queries), data stores, and channels.
- Assign ownership to your architecture and documentation. Find the right person to answer questions.
- Save time by helping your developers, architects and business stakeholders quickly understand and find the information they need.
- Automate your documentation by turning your OpenAPI or AsyncAPI specification files into documentation.
- Turn your architecture into a living documentation that is always up to date.
- Visualize your architecture in a way that is easy to understand.
- Integrate with any broker, schema format and technology in the world, sync schemas into your documentation.
- Turn your architecture into a design tool, helping you capture business workflows and new ideas.
EventCatalog is self hosted. This means you own your own data, and host it wherever you want.
Project motivationβ
Event-driven architectures have been around for decades, and recently we have seen a rise of distributed message based architectures.
With companies providing high levels of abstractions and cloud based services, building event-driven/distributed architectures are becoming more accessible for developers every day.
These architecture styles are becoming popular as they provide teams the ability to create loosely coupled, distributed and highly scalable systems.
Practices like EventStorming and EventModeling are equally becoming popular within teams as they look to map their business and domains into software architecture.
Complexity with event-driven architecturesβ
π₯ Explore the roots of EDA complexity in "Complexity is the Gotcha of Event-driven Architecture"
When you start building event-driven architectures complexity may be hidden. Over time your architecture matures and grows, more producers/consumers, that's when complexity presents itself.
You may see questions start to emerge within your business:
- What messages (events, commands, queries) do we have?
- Why do these messages exist? Whatβs the context?
- What are the payloads of these messages?
- How can I make changes?
- Who is consuming these messages?
These are common questions when building event-driven architectures, but there is a lack of discoverability tools for event-driven architectures to address these issues.
Discoverability and documentation are treated as an afterthought, but what if we could solve this?
What if we could:
- Document our domains, services and messages
- Version domains, services and messages
- Visualize flow between messages in our system
- Define bounded context and visualise our event-driven architecture?
- Bring discoverability to event-driven architectures?
Say hello to EventCatalog.
Staying informedβ
EventCatalog is currently on v2. If you are looking for v1 docs you can find them here.
Something missing?β
If you find issues with the documentation or have suggestions on how to improve the documentation or the project in general, please file an issue for us