The Designer

Jardis is a visual platform. In the Designer (jardis ui) you model your domain on two levels: strategic, the landscape (which contexts exist, how they relate, which language and which rules apply) and tactical, the implementation (aggregates and processes). A Build turns both into production-ready DDD code. This overview is structured along exactly these two levels; each surface has its own detail page. The same steps run headless via the MCP server.

jardis ui

Workspace Board

The entry point: a workspace is a directory with one or more domains. Per domain, the board shows the strategic structure in columns: Subdomains → Bounded Contexts → Aggregates → Rules → Processes. From here you jump into every detail surface.

Strategic Design (DDD)

Before a single line of code exists, strategic DDD clarifies the landscape: which bounded contexts there are, how they relate, which language applies inside them and which business rules bind them.

Context Map

The relationships between bounded contexts, with the canonical DDD patterns. Three views: Strategic (domain classification Core/Supporting/Generic), Tactical and Reconcile, the drift check that verifies declared against real coupling and delivers a findings report.

Steckbrief (Bounded Context)

The Steckbrief describes a bounded context strategically: business model, domain axis (Core/Supporting/Generic), evolution and owner. The same page also holds Schema (the context's tables) and Mapping (DB column to business name).

Governance

The Governance tab holds the context's strategic policies: BC-wide, cross-cutting decisions (e.g. "GDPR-bound", "B2B only"), not process rules and not aggregate invariants. Each policy shows its coverage status. How these policies turn into enforceable rules on the commands is shown by the tactical Rules & Governance.

Glossary (Ubiquitous Language)

The glossary holds the binding language of a context: one row per business name | description | code identifier. This ubiquitous language feeds autocompletion in the mapping and ends up as the business name in the generated code.

Tactical Implementation

Inside a bounded context it gets concrete: aggregates hold the data and its invariants, processes chain the business flows, and rules bind the strategic policies as guards onto the commands. A Build turns all of it into domain code.

Aggregate Designer

Per aggregate you decide which tables belong to it, which entity is the root and how they relate, as an ER diagram with PK/FK/UK markers. The tabs lead from Tables through the Designer to the generated Code, the API specs and the Report. Build generates the code tree.

Process Designer

You model business flows as a node graph: every node routes via onSuccess/onFail, reads cross-BC, calls rule chains and publishes events at the end. A terminal rejection node catches all error paths.

Rules & Governance

This is where the strategic policies get bound via rules onto the commands of the aggregates: Policy → Rule → Command. A bound rule becomes a guard check before the command in the generated code. The three-column board shows in-use and anchoring status.

Code, API & Reports

After modeling you check the result directly in the Designer, without switching to the IDE.

The Code tab shows the generated aggregate tree, read-only in the browser:

The API tab shows the aggregate's surface: commands/queries with their rule chain, entity tree and lifecycle events.

MCP — Headless

You drive the same workspace without a browser via the MCP server:

jardis mcp

Tools are actions (design, build), resources are read-only (read schema, code). The AI agent runs through the same sequence: workspace → schema → design → build → read code. Full details on the MCP page.