6 posts tagged with "Architecture"

Lots of teams already use C4 to model their architecture, whether that's Structurizr DSL, C4-PlantUML, Mermaid C4, LikeC4, or just markdown architecture docs. If that's you, the good news is you can bring that work straight into EventCatalog.

C4 and EventCatalog complement each other nicely. C4 gives you a clear view of your structure: systems, containers, and how they fit together. EventCatalog adds the event-driven detail on top: the events flowing between services, the schemas, who owns what, and how a business process actually runs. Today I want to show you two ways to connect the two.

Your catalog tells you what services exist, what events they produce, what schemas look like. What it hasn't told you is why any of it was built the way it was.

That's the job of Architecture Decision Records. ADRs capture the reasoning behind significant design choices: why you chose Kafka over RabbitMQ, why the Orders domain owns customer address data, why you split the Payments service the way you did. EventCatalog now supports ADRs as a first-class resource, so that reasoning lives exactly where people go when they need to understand your architecture.

More teams are moving AI agents from demos into real systems. Agents are reviewing payments, answering support questions, querying internal data, calling MCP servers, creating tickets, summarizing incidents, and producing work that downstream systems depend on.

That changes the architecture. If an agent consumes information, calls tools, writes data, or produces artifacts, it needs to be visible in the same place as the rest of your system.

EventCatalog 3.41.0 adds first-class agent documentation. You can now document agents alongside your domains, services, events, commands, data stores, tools, and flows.

Every team I've talked to has the same problem. The architecture lives in one place and the diagrams live in another. The documentation is accurate as of six months ago. The Miro board from the last event storming session doesn't match what's actually running.

Today I'm releasing the EventCatalog Miro App v2, a Miro app that turns your EventCatalog documentation into interactive, collaborative design artifacts — and brings your design decisions back into the catalog when you're done.

Your real architecture, imported into Miro with relationships intact

As event-driven architectures scale, an invisible problem emerges: who is producing what, and who is consuming it? A service starts consuming your OrderPlaced event. No ticket. No Slack message. No email. You find out weeks later when something breaks downstream.

At scale, you need governance over these relationships. You need to know when dependencies change, who is affected, and ideally, before it reaches production.

EventCatalog already gives you auto-generated visualizations: Entity Maps, Interaction Maps, and domain views that update as your catalog changes. These are great for understanding relationships between your resources.

But sometimes you need your own diagrams. Target architecture plans. Event storming results. Sequence flows from Miro. C4 diagrams from IcePanel. The stuff that lives in scattered boards, Confluence pages, or that folder someone created two years ago.

EventCatalog 3.3.0 lets you bring those diagrams to your documentation.

Your custom diagrams are now first-class, versioned resources in your catalog. Bring them in from any tool, version them, link them to your domains and services, and even ask AI about them.