Skip to main content

Domain Explorer

Discover and explore any domain modelled with Ontologic. See the dependencies and relations between your objects, and read every use case as a flow — including the ways it can fail.

Not yet on npmWill be released soon.Beta test it
git clone https://github.com/SachaCR/ontologic
cd ontologic && pnpm install && pnpm build
node packages/domain-explorer/dist/cli.js ~/my-app/src/domain
npx @ontologic/domain-explorer ./src/domain

One HTML file out, named after your codebase. Stylesheet, script and data all inlined, so it opens from disk and survives being emailed.

Discover

Any domain, without setup

Point it at a codebase built on Ontologic and it reads the model straight out of the source. Nothing to annotate, no database, no server — and it does not need your dependencies installed.

Relations

What depends on what

What an aggregate holds and what it only names by id. Which repository persists it. Which events each behaviour emits, which errors it can return, and which views are built from those events.

Flows

Use cases, and how they fail

Every command and query drawn as an event-storming board: the happy path left to right, then one row for each way the use case can be refused.

Use case flows

Read a use case as a story

Each row runs left to right as one complete scenario — the command that started it, every aggregate it read or wrote, and where it ended.

Failure paths repeat the prefix on purpose, so a refusal reads on its own rather than as a branch you have to trace back. Here the two refusals come from different places: the repository knows whether the copy exists, and only the aggregate knows it was already lost.

The DeclareBookLostUseCase board: a happy path that reads Book, calls declareLost, writes Book and ends in a BookLostEvent, then two failure paths ending in BookNotFoundError and BookAlreadyDeclaredLostError.
Dependencies

See what an aggregate holds

Every object gets one page — its invariants, a diagram of the aggregate it belongs to, its behaviours, the events and errors those produce, and the repository that stores it.

Follow the same object from anywhere and you land on the same page. The kind of the thing decides what you see, never the link you happened to click.

The Loan aggregate page: its invariants, a structure diagram of the aggregate and the events it produces, then its behaviours.
Overview

And where it contradicts itself

Every count opens what it counted. Beneath them, the findings: an invariant declared but attached to nothing, an event missing from its union, an error whose instanceof is broken at runtime, a use case whose failures were widened to Error.

The same pass that builds the model reports them, with the file and line to go and fix.

The overview: counters for entities, use cases, events, errors, invariants, repositories and read models, above a findings section.

What it finds

Detection keys on Ontologic's base classes and type arguments, never on filenames — so it works whatever you named your folders, and whether your event union lives in its own file or inline.

  • Aggregates and entities
  • Value objects
  • Domain events
  • Typed errors
  • Invariants
  • Repositories
  • Use cases
  • Commands and queries
  • Read models

Start with a domain you did not write

The library example, generated by the tool itself. Search it, filter it, open an aggregate, follow an event to the view built from it.