The three views
Static, Flow, and Scenarios — three perspectives on one model, and how they work together.
ddd-studio maintains one domain model and projects it into three views. Nothing is duplicated: rename a command in one view and it changes everywhere, delete an event and every view reflects it. The views differ in the question they answer.
Flow View — "What happens, in what order?"
The Flow View tells the model as a story. Slices are arranged as columns from left to right, each one a step in the narrative: a book is acquired → a member checks it out → the loan is recorded → …
Each slice column has four lanes:
| Lane | Contains |
|---|---|
| Trigger | The Actor or Policy that sets the step off |
| API | The Command (or Query) being invoked |
| Persistence | The Aggregate (or Read Model) that handles it |
| Event | The Event the step publishes |
Details that make the story readable:
- Example data on tiles. Slice members can carry concrete example payloads, shown directly on the Flow View tiles and editable in a popover — so the story reads with real values, not just type names.
- Narrative-order connections. A read model's incoming arrows follow the flow's story order: no arrow ever comes from an event that "hasn't happened yet" in the narrative. Connections update automatically when slices are reordered.
- Readable arrows. Connections sit behind the tiles by default and come to the front when you hover a tile, together with its incoming and outgoing connections.
Scenarios — "Is the rule actually right?"
Flows show the happy path. Scenarios pin down the rules — including the cases where the model must say no.
In the Scenarios view you attach features to a consistency unit (an Aggregate or a Read Model) and write scenarios as Given–When–Then, laid out in swimlanes:
- Given — the event history that already happened
- When — the command being attempted (or the query being asked)
- Then — the expected events, an expected rejection, or the expected query result
The values are concrete example data, not schemas. The guided editor only offers what the model allows — matching events, commands, and actors — and generates input fields from the artifacts' schemas. New features can be created right in the view, and scenarios are saved and exported with the rest of the model.
Scenarios are also how the model stays honest over time: consistency hints flag outdated scenarios and slices, for example after a schema change or a deleted member, with warnings and badges.
Static View — "What is the structure?"
The Static View is the structural overview: Bounded Contexts as frames, with Aggregates, Commands, Events, Read Models, Queries, Actors, Policies, Event Handlers, External Systems, and Domain Services inside and between them.
This is where you refine what the flow sketched: add schemas and invariants, connect cross-context elements, attach an Actor to a Command or a Policy to an Event. Quick Add suggests the sensible next artifact kinds based on what's already connected to the selected node.
Every artifact has a raw ESDM YAML detail view with live linting next to its structured field editor — the Static View is the natural hand-off point into development, because what you see is exactly what gets exported.
How they work together
The three views are designed as a progression:
- Start in the Flow View. Sketch the story as slices — cheap, fast, and readable by domain experts.
- Secure it with Scenarios. For each rule that matters, write the Given–When–Then cases: the happy path, the rejection, the idempotent retry.
- Harvest the Static View. Step by step, a complete, validated static model emerges — Bounded Contexts, Aggregates, and invariants ready to hand off into development.
The constraint engine keeps all three views consistent the whole way: a scenario can only reference events and commands that exist, a slice can only wire artifacts the model allows — and when the model is ready for development, it exports as JSON or ESDM.