Tools
One tool for the wall the model is built on, and one for checking whether anyone still respects it.
The first exists. The Event Stormer runs event storming and process modelling on the same board — big picture for discovery, process modelling for the commands and policies, software design for the aggregates underneath — because they are three depths of one notation rather than three exercises. The second does not exist yet: a mapper that holds the catalog and the observed estate at the same time and computes the difference, so its interesting output is never the map but the list of edges the map got wrong. Everything here serves one of those two jobs.
One of these is deployed. The other four are not.The Event Stormer is real and usable now — it is doc-hub’s board, and it runs two of this hub’s practices rather than one: event storming and process modelling are two of its three levels. For the rest, the designs are written and the interfaces are decided; the software is not built. The addresses those panels point at are configuration, so the day something is deployed behind one it takes a value change and a restart rather than a rebuild. Until then, thelandscapespage does by hand what the mapper would do continuously.
Tools
Event Stormer
doc-hub’s event storming board, at big picture for discovery, process modelling for commands, policies and read models, or software design for aggregates and screens. The notation is cumulative, so going deeper never invalidates the wall. Written to a plain `.eventstorm` file rather than a photograph.
Open the board (leaves this site)- Planned
DDD mapper
Reads the catalog, draws the context map from the declared relationships, ingests observed integrations from the landscape collector, and produces the conformance verdict for every edge: matches, drifts, unmapped, missing.
Open the mapper (leaves this site) - Planned
Landscape collector
Observes running systems — service-to-service traffic, database access, schema shapes, event topics — and emits the integration edges the system map is drawn from, each with the observation that produced it.
See what it collects (leaves this site) - Coming soon
Language workbench
One term per context rather than one term per company, with the collisions made visible: where the same word carries two meanings, where two words carry one, and which documents and schemas still use the old one.
Read the design - Coming soon
Storm reconciler
Reads an `.eventstorm` file and reconciles it with the catalog: `context` cards matched against bounded contexts that already exist, each command and event attributed to the context that owns it, and every step where the process leaves one boundary flagged as a crossing with no transaction behind it. The board models the process; this says where the process is.
Read the design
What goes in, what comes out
A tool with no named input is a drawing program, and a tool with no named consumer is a hobby. Both columns are filled in for every entry below, which is a cheap way to notice when one of these should not be built.
| Tool | Does what nothing else does | Reads | Emits |
|---|---|---|---|
| Event Stormer | Run both workshops — event storming and process modelling — on one wall, at whichever of the three levels the room is working at. | A room, a facilitator, the people who do the work, and a declared level. | An `.eventstorm` file: candidate bounded contexts from the big picture, the commands, policies and read models of a process, the aggregates under it, and every hotspot nobody could settle. |
| DDD mapper | Hold the catalog and the two landscapes in one place, and compute the difference between them. | The catalog, the declared relationships, and the landscape collector’s observations. | A context map, a system map, and a conformance table with an owner against every finding. |
| Landscape collector | Replace assertion with evidence about what the estate actually does. | Service meshes, database audit logs, broker topic metadata, schema registries. | Observed integrations with evidence, consumed by the DDD mapper. |
| Language workbench | Keep the ubiquitous language honest across contexts. | Catalog language sets, requirement documents, API schemas. | A per-context glossary and a collision report. |
| Storm reconciler | Place a finished wall against the catalog, so its boundary crossings are computed rather than remembered. | An `.eventstorm` file, and the catalog to place it against. | Boundary crossings named with their compensating actions asked for, and new `context` cards raised as catalog candidates. |
And the part a model can do
Some of this work is judgement and some of it is reading. Distilling a first pass at the subdomains out of documents the business already wrote, spotting that one word carries two meanings across four systems, or noticing that an integration nobody declared has appeared — none of those need an analyst, and all of them currently consume one.