English

Deutsch

English

Deutsch

Appearance

Bounded Context Editor ​

Part of the Designer guide. Previous: Context Map · Next: Aggregate Designer.

A bounded context is a closed model unit with its own language and its own API. Besides the aggregates and processes, this is where you maintain the strategic layer: what the context means, which terms apply and where its data comes from.

The Schema tab of a bounded context

Steckbrief ​

The Steckbrief is the dedicated screen for the strategic BC description, opened via the Steckbrief tile on the bounded context.

The Steckbrief of a bounded context

Fields: Description, BusinessModel, Evolution (Genesis / Custom-Built / Product / Commodity), BusinessPolicies and Assumptions (list editors), Owner. The domain axis (Core / Supporting / Generic) is shown read-only: it live-mirrors the classification of the parent subdomain, since a subdomain can span several bounded contexts.

The same screen serves real and planned bounded contexts: for a planned BC (not yet created) you edit the glossary terms directly here and can turn it into a real BC via "Create now" (promote).

Glossary — Ubiquitous Language ​

The glossary holds the binding language of the context: one row per entry, Business Name | Description | Code Identifier.

The glossary editor with business name, description and code identifier

Existing aggregate/field names from the command catalog are suggested as code identifiers, purely advisory, never applied automatically. Saved with an explicit save/cancel (no autosave). The glossary feeds the autocomplete in Mapping.

Governance ​

The Governance tab lists the context's strategic policies. Every policy shows a coverage badge "N rules → M enforcement points" and warns if it remains unanchored ("no rule anchoring") or without an enforcement point.

The Governance tab with policies and coverage status

How policies become enforceable rules on commands is shown on the Rules & Governance page, that's where the chain Policy → Rule → Command comes together.

Schema ​

Jardis works on a table schema per bounded context (Schema.yaml). It's created via import: from a file (SQL dump, JSON export, YAML) or directly from a live DB connection (MySQL, Postgres, SQLite). Connections are saved; passwords stay in memory only. The aggregates pick their table subset from this schema.

Schema from scratch

No existing schema? The schema-authoring skill generates a valid Schema.yaml from a plain-text idea, validated against the format the importer understands.

Mapping ​

The Mapping tab decouples the technical DB column names from the business names in the generated code. One row per column, DB Column → Business Name, with status auto (default) or override.

The Mapping tab: DB columns to business names

Input is saved immediately (overrides only). The business-name input suggests terms from the glossary of the same context. A change only marks the aggregates as affected that actually use that exact table.