One format choice

Why HCL?

The project needed a text format that people can edit by hand and a tool can validate.

JSON is easy to validate but noisy to write. YAML is pleasant to write. HCL has one more feature: domain concepts can be blocks.

The project chose HCL for this experiment.

{ "kind": "event", "name": "student_registered" } kind: event name: student_registered event "student_registered" { }

In this project, the block form helps because the source looks like the concepts that people discuss.

References and validation

event.school.student_registered

HCL parses this as a traversal expression. HCL does not know that it refers to an Event.

The .em.hcl validator supplies that meaning. It checks the reference kind, scope, and existence. A validated model becomes a typed model for the renderer and other tools. The formatter works on one source file at a time.

These checks do not establish business completeness. Review who triggers each action, where each field comes from, and what happens when a decision fails. HCL records the model; it does not replace that review.

Tradeoffs

These formats solve different problems. This table lists the differences that matter for this project.

JSONYAML.em.hcl
Familiar ecosystemVery broadVery broadSmaller
Human editingVerboseCompactBlock-oriented
ReferencesUsually plain dataUsually plain dataHCL traversals plus .em.hcl validation
CommentsNo standard JSON commentsYesYes
StructureBrackets and bracesIndentationBlocks and braces
ValidationJSON Schema ecosystemSchema or tool dependentProject validator
Fit hereInterchangeLightweight authoringDomain-oriented authoring
CostMore syntax noiseSignificant whitespace and YAML semanticsCustom language tooling

Related work

YAML

EmLang

An Event Modeling language and toolchain that uses YAML. It includes editing, validation, and diagram tooling. If YAML suits your team, read about it.

EmLang on GitHub →

YAML

ESDM

Uses YAML manifests to model event-sourced domains. It also provides validation, rendering, and editor tooling.

ESDM documentation →

JSON Schema

Martin Dilger's Event Modeling Specification

A JSON Schema representation of Event Models. It is a main input to this project.

Specification on GitHub →

Use the format that fits

Event Modeling does not require HCL. Start with business facts, decisions, and the information people need, not a choice of syntax. This project explores HCL as one tradeoff.

If JSON or YAML suits your tooling better, use that. The CLI can import and export slice-based Event Modeling JSON, but conversion is not a lossless canvas copy. It warns about details the other format cannot hold.