Found while modeling a real domain in ESDM and browsing it with the visualizer.
Aggregate nodes are rendered, but they are never connected to anything. src/routes/+page.server.ts builds edges for actor to command, command to event, event to read model, and read model to query, so an aggregate always floats on the board without a single edge.
For an event-sourced model, the path from a command through the aggregate to the events it publishes is the central one: the aggregate is what decides whether the command is accepted, and its invariants are what the events have to respect. Right now the board shows commands and events as if they related to each other directly, and leaves the unit that governs them standing beside the picture.
Drawing that relationship, or grouping an aggregate's commands and events visually, would make the board say what the model actually means. This is a design question rather than a defect, so treat it as a suggestion.
Found while modeling a real domain in ESDM and browsing it with the visualizer.
Aggregate nodes are rendered, but they are never connected to anything.
src/routes/+page.server.tsbuilds edges for actor to command, command to event, event to read model, and read model to query, so an aggregate always floats on the board without a single edge.For an event-sourced model, the path from a command through the aggregate to the events it publishes is the central one: the aggregate is what decides whether the command is accepted, and its invariants are what the events have to respect. Right now the board shows commands and events as if they related to each other directly, and leaves the unit that governs them standing beside the picture.
Drawing that relationship, or grouping an aggregate's commands and events visually, would make the board say what the model actually means. This is a design question rather than a defect, so treat it as a suggestion.