Skip to content

Why Moment

No tool in the DDD or Event Sourcing ecosystem lets you test domain flows before you write implementation code. Moment is the first.

The problem

Domain knowledge fragments on contact with code

Your team runs an Event Storming. You map bounded contexts on a whiteboard. Then someone opens an IDE and starts writing types. Someone else writes tests. A third person updates the wiki. A fourth defines the API contract.

By the end of the sprint, you have six representations of the same domain model. They already disagree.

Flows are the untested frontier

Most teams test individual commands and queries. Very few test the flows between bounded contexts — the temporal sequences where events cross boundaries, contracts are exchanged, and sagas coordinate long-running processes.

These flows are where the hardest bugs live: race conditions, broken contracts, missing compensation logic, and orphaned events. And they're exactly what nobody writes tests for.

Boilerplate doesn't scale

Every new aggregate means writing TypeScript interfaces, aggregate classes, test stubs, Gherkin scenarios, specification documents, and API contracts. Multiply by every bounded context. Multiply by every change.

The cost isn't just time — it's drift. Manual artifacts diverge from intent. Tests cover the wrong cases. Documentation describes last month's model.

How Moment solves it

1

Single source of truth

The .moment specification is the canonical definition of your domain. Contexts, aggregates, commands, events, flows, crossings, sagas, policies — all in one file, in one language, version-controlled alongside your code.

2

Temporal modeling with flows

Flows define how events move through time across bounded contexts. Lanes, moments, branches, crossings with contracts, triggered-by chains, and terminal states make the temporal dimension explicit and testable.

3

Deterministic artifact generation

Same input, same output. Every time. TypeScript types with discriminated unions, test scaffolds with crossing assertions, Gherkin features with flow coverage, spec docs with Mermaid diagrams, and AsyncAPI contracts. Six artifact types from one specification.

4

Drift detection closes the loop

moment drift compares your specification against implementation using AST-level diffing. When they diverge, you know exactly what changed, where, and why. Reconcile in either direction.

The breakthrough: test your domain before you code

Moment + Facet: simulate, visualize, then implement

Run moment simulate to generate Facet-compatible simulation scenarios from your specification. Each scenario includes synthetic events with causation chains, correlation tracking, and branch path resolution.

Load the scenarios into Facet to see your domain flows rendered as interactive timelines. Validate that events flow correctly between bounded contexts. Verify crossing contracts carry the required fields. Confirm saga states transition in the right order. See which branches lead to terminal states.

All of this happens before you write a single aggregate class, command handler, or event listener. When you do start implementing, you're building against a domain model that's already been visually validated. Your test scaffolds, Gherkin features, and TypeScript types are generated from the same source of truth.

Why this doesn't exist anywhere else

DDD tooling today starts at the code level. You model with EventStorming, then jump directly to implementation. There's no intermediate step where you validate the temporal behavior of your domain.

Event Sourcing frameworks give you event stores, projections, and aggregate persistence. But none of them let you simulate event flows from a specification and validate them visually before building the system.

Moment bridges this gap. The .moment DSL captures temporal behavior (flows, crossings, branches, triggered-by chains) that no other specification format can express. And the moment simulate command turns that specification into executable scenarios that Facet can render.

How Moment compares

Moment isn't a code generator. It's a specification-driven toolchain that produces artifacts you'd write by hand — but can't keep in sync manually.

Manual DDD OpenAPI / Swagger GraphQL Schema-First Moment
Source of truth Wiki + code + tests API spec (YAML) Schema (SDL) .moment specification
Domain modeling Whiteboard / Event Storming Endpoints only Types only Contexts, aggregates, flows, sagas, policies
Generates types Manual Yes Yes Yes (discriminated unions, readonly)
Generates tests Manual No No Yes (scaffolds + Gherkin features)
Generates docs Manual Swagger UI Schema introspection Spec docs with Mermaid diagrams
Simulate before coding Not possible Not possible Not possible Yes (moment simulate → Facet visualization)
Temporal flows Not modeled Not modeled Not modeled First-class (lanes, crossings, branches)
Drift detection None None None AST-level diffing
Schema governance Manual versioning Version in URL Deprecation directives 4-phase lifecycle (Active → Deprecated → EOL → Removed)

Who Moment is for

Architects

  • Enforce bounded context boundaries with crossing contracts
  • Govern schema evolution across teams with lifecycle policies
  • Detect specification drift before it reaches production
  • Visualize context maps and flow timelines from the spec

IC Engineers

  • Stop writing boilerplate types, tests, and docs by hand
  • Get pre-populated test scaffolds with crossing assertions
  • Trust that generated code matches the domain model
  • Use watch mode for instant feedback during development

Team Leads

  • Onboard new engineers with a readable domain specification
  • Ensure consistency across bounded contexts and teams
  • Living documentation that never drifts from implementation
  • Adopt incrementally, one context at a time

Ready to try it?

Start with one bounded context. Write a .moment file. See what Moment generates.