The architecture manifest is an index of every domain, service and contract, but most people will never open that YAML file. EventCatalog is the website that shows the same index. A generator collects the pages from the APIs that the teams already publish, and a release pipeline keeps the website current.
Agentic development makes software cheaper to produce. That does not reduce the need for software engineering. This is a public hypothesis: keep the understanding of the system explicit, generate what is already decided, then use the result from the customer's perspective and feed what you learn back into the model.
As Arcadia Editions grows, nobody sees the whole system in one place. A single YAML file, zenwave-architecture.yml, points at every domain, service and contract and how they connect, without copying any of them. The pipeline keeps it current. Humans, tools and agents can all navigate from there.
A domain model and the APIs it generates are not implementation details of a service. They are the contracts every consumer depends on, so they need the same lifecycle as any other product: quality, versions, publishing, and a place where people can find them.
Writing YAML by hand is no fun, but you can generate your OpenAPI and AsyncAPI definition files from a Domain Specific Language instead. With ZenWave SDK you convert a compact ZDL model into those contracts, saving time and effort while keeping your APIs aligned with best practices and standards.
AsyncAPI's $ref lets a client spec point to a provider spec without duplicating it. When that spec drives both application contracts and infrastructure provisioning, the URL behind the $ref is an important decision to answer. A pinned version, a environment alias, or the tip of main: each offer different trade-offs.
The AsyncAPI spec says an application SHOULD describe its operations, but not necessarily all of them in the same spec file. Not all operations are equal: some define the public API surface, what the application offers; others describe internal dependencies, what it needs. It makes sense to model them separately.
ZDL is a compressed blueprint of the business: aggregates, commands, events, and lifecycles captured in one readable model. The point is not that generation replaces design, but the opposite: because the design is written down as ubiquitous language, generation can preserve it across contracts, code, documentation, and tests.
ZFL describes a business flow with commands, events, services, and sometimes aggregate names. An AI agent can turn that into scaffolding for your service repositories.
Event Storming has two phases. First you discover the flow. Then you find the centers of gravity. The service field in ZFL is where that second phase becomes explicit, and where you start building the architectural world model.
Large systems become unmanageable when everyone shares the same model. This post walks through the heuristic we used to find those boundaries in Arcadia Editions, looking for the business objects that act as centers of gravity for commands and events, and using the consistency requirement to draw the line around each one
Event Storming gives you sticky notes. ZFL gives them a structured home. Here is how the concepts map.
API First should not stop at generated code. In event-driven systems, the same AsyncAPI contract should help producers, consumers, and platform teams understand and provision the infrastructure that makes the API real.
We know what Arcadia Editions wants to deliver. Now we need to discover how. Event Storming is how you turn that conversation into a shared understanding of the business. This is what that looks like in practice.
The solution space is your business. But only if it needs to be discovered. If it is already known, you are not building a business, you are building a commodity.
Domain discovery, event modeling, API specs, and running code. All of it built in the open, through a domain complex enough to make the decisions interesting.
Three upstream fixes that make the Apicurio Registry Maven Plugin work from the CLI with minimal configuration
AsyncAPI Studio was previously a single in-memory file editor. This prevented using relative $refs to external .avsc Avro files. This new contribution now tracks the document source, resolves relative references, and can read and write files directly to disk using the browser's File System Access API when working with a local folder.
Every application has state machine-like transitions: an order that gets placed, paid, shipped, cancelled. Now you can model your state transitions and ZenWave SDK will implement and enforce them for you.
How strongly-typed code generation, build-time regeneration, and versioned specifications eliminate API drift in Java/Spring projects using OpenAPI and AsyncAPI.
En este artículo exploraremos cómo utilizar ZenWave360 para generar un proyecto completo de Spring Boot con Kotlin a partir de un modelo DSL de Lenguaje Ubicuo.
How to use ZenWave SDK to implement DDD principles in practice, from Event Storming discoveries to a complete Spring Boot Kotlin project using ZDL as Ubiquitous Language.
Análisis práctico del desarrollo con Spring Boot usando Kotlin frente a Java, comparando sintaxis, productividad e integración con herramientas como OpenAPI, AsyncAPI y Avro en un entorno empresarial.
Announcement of ZenWave SDK 2.0.0 release and upcoming Kotlin support for generating well-structured Spring Boot applications with OpenAPI and AsyncAPI support.
Evita errores y pérdida de alineación en tus APIs asíncronas. Descubre cómo AsyncAPI y ZenWave SDK pueden ayudarte a prevenir el API Drift mediante generación de código automatizada y buenas prácticas DevOps.
Aprende a implementar un Outbox Transaccional con AsyncAPI, SpringModulith y ZenWaveSDK, garantizando la consistencia y externalizacion eficiente de eventos en arquitecturas distribuidas.
Implementing transactional outbox pattern using AsyncAPI, Spring Cloud Stream, and Spring Modulith as part of ZenWave 360º approach.
Introducing a new library that provides a Spring Modulith event externalizer for Spring Cloud Stream, enabling multi-broker support, flexible message headers, and Avro serialization.
How to save time and typing by generating KarateDSL tests automatically from OpenAPI definitions using ZenWave SDK.
Use ZenWave Domain Language (a compact DSL) as IDL to generate OpenAPI v3 specs instead of hand-writing YAML.
The only free and open-source way to debug KarateDSL scripts in Visual Studio Code, bringing back first-class debug support.
A guide to Event Storming as a collaborative workshop technique for exploring complex business domains, and how ZDL maps Event Storming discoveries into a developer-friendly format.
How ZenWave 360º enables business domain modeling using DDD principles, ZDL as Ubiquitous Language, and ZenWave SDK to convert domain models into software artifacts.
Convert JHipster JDL models into AsyncAPI definition files using ZenWave SDK.
Convert JHipster JDL models into OpenAPI definition files using ZenWave SDK.
Applying API-First principles using AsyncAPI, similar to the OpenAPI process.
Generate strongly typed Java interfaces, DTOs, and headers from AsyncAPI definitions using ZenWave SDK plugins.
Create high-fidelity stateful mocks for REST APIs using OpenAPI, KarateDSL, and ZenWave APIMock for contract testing.
Guide to moving from manual testing to contract testing using OpenAPI, KarateDSL, and the KarateIDE VSCode extension.