What is ESDM

ESDM is the Event-Sourced Domain Modeling language. It lets you describe an event-sourced domain – Domains, Bounded Contexts, Aggregates, Events, Commands, Process Managers, Read Models, and the relationships between them – as a set of YAML files, and then check those files for consistency, completeness, and structural soundness.

The language has two ingredients. A schema that defines what an ESDM document may contain, and a linter that reads your documents, parses them against the schema, and reports problems where the model does not hold together. You write models as plain text. ESDM tells you what is missing, what is inconsistent, and what is suspicious.

Why a Modeling Language

Event Sourcing and Domain-Driven Design come with a lot of vocabulary – Aggregates, Bounded Contexts, Process Managers, Dynamic Consistency Boundaries, Read Models, Context Mappings. In practice, the language is shared, but the artifacts are not. Teams capture their models in slide decks, whiteboard photos, README files, or scattered code comments, and the model drifts the moment it leaves the room.

ESDM gives the model a first-class home. The model is files, the files live next to the code, the files are reviewed in pull requests, and the linter prevents quiet erosion. When someone introduces an Event without a publisher, or a Bounded Context without a single Aggregate, the linter says so before the change lands.

The schema captures the structural rules – what fields exist on each kind, which references must resolve, which combinations are forbidden. The linter captures the modeling rules – the patterns that experienced practitioners learn to recognize but that are easy to overlook in the moment.

What ESDM Is Not

ESDM is not an event store, not a runtime, not a code generator, not a framework. It does not execute your domain. It does not know about your database, your message bus, or your deployment pipeline. It is a static, descriptive layer that lives alongside your code and helps you keep the model honest.

That separation is deliberate. A modeling language that tries to also be a framework forces you into specific runtime choices, and a runtime that tries to also be a modeling language buries the model under implementation detail. ESDM keeps the two apart so you can mix it freely with whatever you actually run in production.

Where to Go Next

If you want to see ESDM in action, head to Installing ESDM and write your first model. If you want to understand the vocabulary first, the Concepts section walks through every kind the core schema defines. The Reference section is the canonical place to look up a CLI command or a schema field once you're past the basics.