Skip to main content

3 posts tagged with "CLI"

Explore EventCatalog articles and updates about CLI.

View All Tags

Introducing Architecture Fitness Functions for EventCatalog

· 10 min read

Your team agrees that services in the Ordering domain should never read from the Payments database. If Ordering needs to know about a payment, it listens for an event or calls the Payments API. You write it down, maybe in an ADR, and everyone nods.

Six months later, someone adds the Payments data store to the Order Service's readsFrom. It was the quickest way to get a feature out. The catalog now documents the dependency perfectly. It doesn't tell anyone that it breaks a decision you made.

That's the gap I keep seeing. Teams spend real time documenting their architecture and agreeing on how it should look, but nothing checks that it still does.

Architecture fitness functions close that gap. The idea comes from Building Evolutionary Architectures by Neal Ford, Rebecca Parsons and Patrick Kua: a fitness function is an automated check that tells you whether your architecture still meets a goal you set for it. Your architectural decisions stop being something people have to remember, and become something that passes or fails.

So we built them into EventCatalog. You can now write architecture fitness functions for your catalog: rules about your architecture, written in TypeScript, that run against your catalog and tell you which resources break them.

Share your architecture with anyone: export your catalog as one HTML file

· 9 min read

Every now and then, someone asks for "a copy of the architecture".

It's never the people who can already open your catalog. It's the partner integrating with your payments, the auditor who needs to know where personal data lives, the team at the company you just acquired, the contractor who is still waiting on VPN access. They need to understand part of your architecture, and they can't get to where it's documented.

So someone opens the catalog, takes twenty screenshots and pastes them into a doc. By next month it's out of date.

API teams sorted this out years ago: write an OpenAPI file, generate a reference from it, send it to anyone. I wanted the same thing for a whole architecture, and a few of you have asked for it too.

So we built it. You can now export your catalog as one HTML file: all of it, or just the part someone needs. Every domain, system, service, message and flow in it is linked to everything it relates to, and it's written again every time you build.